## Summary Security Findings

The National Strategy to Secure Cyberspace (NSSC) gave the DoC Task
Force the charge "*to examine the issues related to IPv6, including the
appropriate role of government, international interoperability, security
in transition, and costs and benefits."* While this explicit tasking
covers all aspects of the costs and benefits of IPv6, its context within
the NSSC clearly implies that issues of security where to be a primary
focus of the study. This section summarizes the security findings
documented in more detail in other sections of this report.

The findings of this study indicate that there are potential security
needs for, and several potential security benefits of, the eventual
adoption and use of IPv6 within the civilian Government and the Internet
as a whole. At the same time, the findings indicate that the greatest
potential security benefits appear to be associated with the long term
evolution to new security paradigms, significantly different than those
commonly employed in today's networks. As a result, these potential
security benefits are balanced by what might be considerable development
costs to complete the design and development of these new models and
potential increased risks to incrementally deploy and transition to them
in existing operational networks. With respect to the near-to-mid term,
the study also indicates that careful integrated security planning, IPv6
specific security development, and security testing should proceed any
agency specific decision to operationally deploy new IPv6 technologies
so as to insure the security and stability of both the new IPv6
resources and the existing resources that they may interact with.
Failure to do so could easily result in degrading the security posture
of existing federal IT systems.

As documented in the previous sections of this report, the security
issues associated with IPv6 technologies are complex and span multiple
realms, including: explicit and implicit IP protocol security features;
interactions with numerous supporting security technologies; varied use
cases scenarios, threat models, and security requirements; multiple
transition mechanisms and deployment scenarios; and, multiple
architectural views of where and how network security is to be
implemented. Any overly simplistic statements such as "IPv6 is more (or
less) secure that IPv4" that do not address these issues in some
specific context, are most likely meaningless. The sections that follow
attempt to summarize some of the key security issues associated with
IPv6 technologies in appropriate contexts.

### Explicit and Implicit IP Security Features

**IP Security Services (IPsec):** As is documented in section (2.1.2),
IPv4 and IPv6 both rely on the same IPsec architecture and protocol
mechanisms to provide network layer origin authentication, integrity,
and privacy services to applications. There is no appreciable technical
difference in the way IPsec is implemented in either protocol. While it
is often pointed out that IPsec is mandatory in IPv6 and optional in
IPv4, there appears little evidence that IPv4 suffers from a lack of
availability of IPsec implementations, nor that mandating its support in
IPv6 would result in any significant increase in IPsec actual use in
today's networks.

How and where IPsec services are provided in today's networks are
predominately determined by: (1) network-centric security architectures
and trust models that typically build secure virtual private networks
(VPNs) between trusted enclaves and assume trust within individual
enclaves; and (2) the scalability and availability of security
management infrastructures (e.g., policy, key, and trust management
infrastructures; policy enforcement systems; intrusion detection
systems; and security audit and testing technologies); and (3) the
assumption that the composition of networks and trust relationships
between nodes are relatively static. All of these factors contribute to
what is typically know as a *network-based (or perimeter) security
architectures* in which the provision of security services and the
enforcement of security policies are implemented at the perimeter of
network enclaves. The trade-offs between this common current model and
potential future *host-based (or end-to-end) security architectures* are
discussed further below; but absent the development of, and evolution
to, new security paradigms one would not expect IPv6 to result in
significantly greater use of IPsec than that found in IPv4.

**Securing IP Control Protocols:** IPv6 provides support for various
configuration (e.g., neighbor discovery, addresses auto-configuration,
router discovery, renumbering) and control (e.g., path MTU discovery)
capabilities. These capabilities are richer, and better integrated, than
the auto-configuration capabilities typically found in today's IPv4
networks and should result in reduced administrative costs associated
with the operation of large scale networks and potentially more
stream-lined implementations of some protocol functions (e.g.,
fragmentation).

While there are clear operational advantages to these auto-configuration
and control capabilities, IPv6's fundamental reliance on their operation
also creates new threats and vulnerabilities associated with their
potential misuse. This, coupled with the desire to support host-based
security architectures in which trust among local nodes is not assumed,
requires that new levels of scrutiny be given to the security of the
IPv6 Internet Control Message Protocol (ICMPv6) and its uses in neighbor
discovery, and address auto-configuration. In addition, most IPv6
auto-configuration mechanisms make significant use of multicast, anycast
and scoped addressing capabilities. Care must be taken to ensure that
network security systems limit the extent to which these new modes of
addressing are not exploited as new attack vectors by compromised hosts.

The IETF has taken steps to address some of these concerns through the
development of specifications for secure neighbor discovery and
cryptographically generated addresses (CGAs). Additional work remains to
complete additional specifications (e.g., proxy neighbor discovery) and
define best common practices for the secure use of IPv6
auto-configuration capabilities. While IPv4 makes less extensive and
required use of auto-configuration technologies, its control protocols
(e.g., ARP, ICMP) have many similar vulnerabilities to insider attacks
and abuse, but there is little development on the horizon to address the
issues in a manner similar to IPv6.

**Security Implications of Addressing:** As documented in section 2.1.1,
one of the prime motivations for the design and eventual adoption of
IPv6 is its vastly larger (128-bit) address space. While most of the
design motivation for wanting larger addresses has focused on avoiding
perceived looming shortages of globally unique IPv4 addresses and
restoring global end-to-end addressability to the Internet (see Network
Address Translation (NAT) discussions in sections 2.1.1, 2.1.5 and
2.1.6), recently much greater focus has been given to the security and
privacy implications of various global and local addressing mechanisms.

***Address Obscurity**:* Many common IPv4-based network attack scenarios
begin with brute-force address enumeration scans of entire subnets,
sites, or the Internet as a whole. In typical IPv4 deployments, once an
assigned address prefix is known, an attacker only has to scan between
2^8^ (subnet) and 2^16^ (site) addresses to find every host. One well
documented security advantage of the IPv6 address structure is that its
64-bit space for individual interface IDs is so vast (2^64^) that
brute-force enumeration scans of the address space are rendered
practically infeasible. In order to fully realize this benefit care must
be taken to avoid overly simplistic interface ID assignments (e.g.,
sequential, embedded IPv4 addresses), and, in fact, is best realized in
large networks by employing random privacy addresses or
cryptographically generated addresses.

One interesting side effect of this situation is that network
administrators also lose the ability to perform brute-force address
scans for the purposes of security auditing and testing. In fact many
popular IPv4 security analysis tools are fundamentally based upon
address scanning. Thus finding and identifying misconfigured hosts, or
compromised hosts that are purposefully "hiding", on an IPv6 subnet may
be equally impossible. This implies that in IPv6 networks, both network
administrators and would be attackers must look else where (e.g., DNS,
server logs, neighbor discovery caches) to gather lists of active hosts.

***Address Privacy**:* An early, primary design philosophy of IPv6 was
that every host (i.e., network interface) will be assigned one or more
globally unique and routable address. The basic unicast addressing
architecture calls for such addresses to be comprised of a 48-bit global
routing prefix, followed by a 16-bit site subnet identifier and ending
with the 64-bit interface ID. Initial designs for the interface ID
called for the use of global extended unique identifier (EUI-64)
encodings such that a given hardware interface could be identified, and
tracked, independent of its currently assigned 64-bit routing prefix.

In recent years, the use of IPv4 "private" addresses (i.e., not globally
unique, nor globally routable) and NAT has become prevalent in many IPv4
network scenarios. While there is much debate about the desirability,
security properties and long term architectural implications of IPv4 NAT
and private addressing, there is growing general recognition of
perceived benefits of some degree of local address autonomy, global
address privacy and site topology hiding capabilities in networks. While
one can argue that IPv4 private address and NAT provide some level of
these attributes, there are no direct ways of supporting similar
properties with IPv4 global addresses.

Address privacy implies the ability to significantly obscure the
association between observed network addresses and specific individuals
or hosts, and to obscure the correlation between a long series of
communications by a single host. The IETF is currently developing
specifications (i.e., IPv6 Network Architecture Protection (NAP)) to
enable such capabilities based upon the use of constantly changing
privacy addresses or cryptographically generated addresses.

Local address autonomy implies the availability of a set of addresses
that are independent of currently assigned global routing prefixes and
that are only routable within a prescribed administrative domain. Such
addressing has perceived value in terms of allowing provider independent
addresses for local communications that do not have to change if your
ISP changes, and for providing some minor confidence that such addresses
can't be used as targets of attacks from remote (outside the domain)
attacks. In IPv4, such private addresses are commonly used for some
control/management ports within router networks and host addressing in
small to medium sized enterprises. Work is underway in the IETF to
develop specifications for Unique Local Addresses (ULAs) to provide
similar capabilities for IPv6.

Topology hiding implies the ability to obscure the number, connectivity,
and population of individual subnets within a given administrative
domain. Here, once again, one could argue that IPv4 NAT can provide such
capabilities by multiplexing a set of private internal addresses onto an
unrelated set of publicly visible addresses. Schemes are under
development in the IETF to use untraceable IPv6 addresses or internal
mobile IP to provide similar capabilities for IPv6.

While there is on going work in the IETF to develop IPv6 address privacy
mechanisms, there are outstanding unresolved questions about their
potential impact on address registries, the domain name system, routing
systems, etc. In addition, much like the issues of address obscurity,
addressing privacy concerns present a double edged sword. While their
design is to prevent those with malicious intent from gaining
information about the behavior of specific hosts and the structure of
individual networks, they also can hamper those trying to gain such
information for constructive purposes such as identifying sources of
attacks, etc. In fact, some techniques like rapidly changing privacy
addresses resemble the address common spoofing techniques of attackers
and would thus be in conflict of network intrusion detection systems
designed to identify such threats.

***Address Semantics:*** While the sections above primarily addressed
issues with unicast addressing, IPv6 inherently supports other modes of
addressing (e.g., multicast, anycast, scoped unicast) that are not
typically found in IPv4 operational deployments. While these new
addressing capabilities present significant opportunities for the
development of new network capabilities and services, it is also fair to
say that security mechanisms and practices for these new modes of
addressing are not as mature and well understood as those for global
unicast. Additional efforts are needed to develop security solutions
that can enable secure multicast and unicast communications and to
ensure that these capabilities do not create new vulnerabilities in the
networks in which they are deployed.

### Current and Future Security Architectures

Much of the analysis and debate of the security implications of IPv6
versus IPv4 center on issues much more fundamental than the explicit and
implicit security features of either protocol. The more basic issues
focus on the long term viability of current and future security
architectures, trust models and enforcement technologies. Current common
IPv4 security architectures rely on perimeter-based middle-boxes (e.g.,
firewalls, NATs, intrusion detection systems (IDSs), security gateways)
to provide security services between trusted enclaves. While one could
argue that the current model fits well with today's network dynamics,
trust models, and the capabilities of current security technologies;
future network requirements may well require distributed security
architectures that address more diverse and ephemeral models of network
organization, trust, and security enforcement. One key perceived
requirement of future host-based security architectures is the direct
support of end-to-end network layer security services between hosts and
applications. Such end-to-end security models are in conflict with many
current perimeter-based middle-box technologies such as NATs[^1], IDSs,
etc. In the section that follows we examine these issues in more detail.

**Network Centric Security Architectures:** As noted in prior sections,
today's common perimeter-based security models assume fairly constrained
and static views of network composition, topology and trust models.
While perimeter-based models can be hierarchically deployed (i.e.,
"defense in depth"), often at the lowest levels there are few explicit
security mechanisms; instead relying on "local trust" at the subnet, or
site level. One obvious ramification of this approach is that at some
level, insider threats may well go undetected and undeterred.

Such perimeter models require the ability to identify and carefully
control the topology of protected enclaves. Typical deployments consist
of a very limited number of inter-connection points where links are
typically partitioned into external, internal private, and internal
public segments (for externally visible servers). Middle-box security
devices sit at the intersection of each of these segment types carefully
enforcing site-wide security policies, providing security services and
monitoring traffic for security events. VPNs (i.e., IPsec tunnels) are
often used to security connect one trusted enclave to another and NAT is
often used so that the internal-private parts of the enclave can use
private addressing.

The advantages of perimeter-based security models are that they focus
site security definition, management, enforcement and auditing at a very
limited number of points in the network. Typically these perimeter
security points are under the total control of enterprise security
organizations and are some of the most highly maintained and monitored
assets in enterprise network infrastructures. Centralized monitoring and
audit functions allow for easy integration with other corporate
information assets such as equipment inventories, employee directories,
etc.

**Host Centric Security Architectures:** While network-centric security
models could be thought of as the best common practices for today's
networks, there are growing needs for new models of network composition,
trust and security services. The growing importance and acceptance of
nomadic devices (e.g., laptops, PDAs, IP phones, sensors), self
organizing systems (e.g., mobile ad-hoc networks; service oriented
software architectures; and peer-to-peer systems), environments with
untrusted local links (e.g., public wireless access points, multi-access
residential broadband) may indicate that traditional perimeter (e.g.,
firewall) models are becoming obsolete.

With the adoption of IPv6, the opportunity exists to develop new
host-centric security architectures that distribute policy enforcement,
security services, intrusion detection, etc. to multiple points in the
network as required for the given deployment scenario. In such
architectures, security policies can be defined at the finest
granularity required. No longer would coarse site-wide security policies
inhibit individual hosts from deploying new applications and services
that need to deviate from the norm. The implicit distributed security
enforcement architecture could be realized in a hybrid manner, with some
policies and services implemented in a perimeter model and others
residing on individual hosts.

IPv6 is thought to be better suited to enable such host-based security
models because of its provision of globally unique and routable
addresses to all systems and the mandated support of IPsec in all
implementations. These attributes, and the assumed elimination of NAT
and other middlebox functions that inhibit end-to-end IPsec, provide the
basis upon which host-based security architectures could be built.

IPv6 can also be thought to itself contribute to the obsolescence of
traditional firewall architectures as many of its capabilities (e.g.,
end-to-end connectivity, tunneling, encryption), if enabled, make
perimeter control difficult. Basic IPv6 packet construction complicates
middlebox inspection of its data.

**Evolution of Security Architectures:** While there seem to be
legitimate requirements for, and potential benefits from, the adoption
of new host-centric security architectures, it should be recognized that
much research and development needs to occur before such models can be
realized in real networks. Host-based security architectures are
inherently more complex than centralized, network-based models.

To date, the standardization and development of the security management
infrastructures and enforcement technologies necessary to support a
distributed host-based security architecture is immature. In order to
support hybrid, distributed models of security policy management,
enforcement, monitoring and audit considerable research and development
remains to be done. The design, standardization and testing of
commercially viable technologies for security policy information models,
policy specification languages, policy management protocols, distributed
enforcement mechanisms, distributed monitoring mechanisms, boot strap
network access control and auditing technologies must proceed practical
deployment of host-based architectures in large scale environments.

It should be noted that the simple adoption of IPv6, and the
re-establishment of the potential of ubiquitous end-to-end networking
capabilities, alone may not result in significant changes in practical
security architectures. Until most of the required new security
management infrastructure and enforcement mechanisms are in place to
enable host-based security, it could be expected that large IPv6
installations will implement perimeter security mechanisms, similar to
those in use with IPv4 today.

Once such host-based security capabilities are fully developed,
additional study must be given to how organizations might transition
from one security model to the other.

### Security in Co-existence and Transition

IPv6 was designed with security and transition in mind; but one could
argue that "secure transition" remains an area requiring additional
significant attention. The importance of security in co-existence and
transition is highlighted by the expectations that transition to an IPv6
dominate Internet may require decades and that some IPv4 technologies
may well continue to be used for the foreseeable future.

One significant finding of this study is that all organizations must
develop security plans for coexistence, independent of their own
decisions and schedules about IPv6 adoption and transition. IPv6
capabilities already exist in most networks with reasonably recent host
and router deployments. The fact that IPv6 capabilities are shipped by
default in many common host and router operating systems implies that
they may be "turned on" at any time, either on purpose, by accident, or
for malicious purposes. Some systems may ship IPv6, and/or any one of
its transition mechanisms, enabled by default. On some existing
platforms, enabling the IPv6 protocol automatically enables various
transition mechanisms.

These observations, coupled with the fact that the "black hat" community
is rapidly adopting IPv6 and already using it to initiate attacks and
hide malicious processes and communications, indicate that all
organizations should develop explicit plans to provide, or prevent, IPv6
communications. Failing do so will create the real potential that IPv6
will appear and be used on an organization's networks either by accident
or for malicious intent.

IPv6 provides numerous dual-stack, tunneling and translation
mechanisms[^2] (e.g., DSTM, SIT, ISATAP, Teredo, NAT-PT, TRT, IPsec
NAT-T) to accommodate a wide variety of co-existence and transition
scenarios. In developing deployment and transition plans one should
observe the adage that "complexity is the enemy of security". The more
complex co-existence and transition becomes, the greater danger that
security vulnerabilities will be introduced into the system.

Each IPv6 transition mechanism was designed with specific scenarios and
requirements in mind. Careful selection and control of their use in
actual deployments is required. Tunneling and translation mechanisms can
complicate, or subvert, typical firewall and intrusion detection
services in today's networks. Dual-stack nodes may provide IPv6 global
connectivity to systems that assume private IPv4 address semantics.
Mandatory support for tunneling may invalidate simple assumptions about
the topological relationship of "neighboring" nodes. While few system
vulnerabilities derive exclusively from the IP layer, the combination of
relatively new networking software and application interfaces will
likely result in new bugs and threats until sufficient community wide
operational tests and evaluations have occurred.

**Incorporating IPv6 in Existing Security Architectures:** It is
expected that most initial deployments of IPv6 will involve
incorporating IPv6 requirements into existing security architectures. In
developing IPv6 deployment and security plans, organizations must be
cognizant that IPv6 is a new and different protocol from IPv4. IPv6
security policies that are comprised of simple cut-n-paste translations
of those for IPv4 are not adequate. As noted in previous sections there
are many new services, protocol functions, addressing semantics, and
packet formats to consider. There are new threats associated with some
of these features (e.g., routing headers, auto-configuration, options
processing, multicast) that require new security analysis and explicit
incorporation into security policies.

Careful evaluation and test of security systems (e.g., firewalls, IDSs,
auditing tools) should be conducted to determine their capabilities to
support IPv6 co-existence and specific transition mechanisms. In
particular, evaluation of firewall and IDS capabilities to do deep
packet inspection of tunneled and translated packet formats may be
required. Such evaluations should include an analysis of the impact and
support of multicast, anycast, privacy addresses, etc. Security test and
audit tools that employ address and port scanning may need to be
modified to deal with IPv6 address space issues.

**Needs for Co-existence Test, Evaluation and Guidance Resources:**
While IPv6 transition mechanisms have been carefully designed for
specific interoperability scenarios, there is still much to be learned
about the practical impact of their deployments in large organizations.
Additional resources need to be devoted to the development of large
scale test and evaluation capabilities, the evaluation of the impact of
various transition mechanisms on typical security architectures, and the
development and documentation of best common practices for new security
policies and management mechanisms capable of ensuring the security and
stability of networks in transition.

[^1]: While there are numerous debates about various architectural and
    operational implications of NAT, in this section we limit the
    discussion to the implications for security. See sections 2.1.1,
    2.1.5 and 2.1.6 for further discussion of NAT issues.

[^2]: It is beyond the scope of this discussion to examine the security
    details of each of these mechanisms and their use in various
    combinations and scenarios.