INFORMATION ASSURANCE AND THE TRANSITION TO IP VERSION 6 (IPV6)

Transcription

1 Abstract This paper presents an analysis of IPv6 and its support protocols from the point of view of Information Assurance. It describes the IPv6 protocol suite, compares and contrasts it to the IPv4 protocol suite, and identifies IA issues that will arise during a migration of core networks from IPv4 to IPv6. It identifies decisions that will have to be made by policymakers, and provides recommendations on the best way to proceed. I. INTRODUCTION Recently, a customer asked us to provide basic guidance about the types of IA issues that a transition of core networks from IPv4 to IPv6 will raise and, as best we could determine, the severity of each issue and its urgency. This paper is a summary of our analysis. A. GENERAL APPROACH The focus of this paper is on IPv6 as a replacement for IPv4 and we approach the information assurance issues from that perspective. In particular, we assume that IPv4's IA properties are a known quantity and that over the years of using IPv4, users have developed a set of operating procedures to achieve an acceptable level of IA using IPv4 in their networks. Thus the key focus of this analysis is with aspects of IPv6 that substantially differ from IPv4 and may make IPv6's IA properties different from IPv4 (either positively or negatively) and/or may force changes in network operations (or, indeed, may make IPv6 more or less suitable for use). With this perspective in mind, we examine how IPv6 differs from IPv4, and for each difference consider the following IA issues: INFORMATION ASSURANCE AND THE TRANSITION TO IP VERSION 6 (IPV6) Does the difference make it easier or harder for a third party to send damaging or unwanted traffic to a system? We are particularly concerned with changes that make it easier to send such traffic anonymously, as it is difficult to take counteraction against anonymous traffic. Does the difference create or eliminate a covert channel? 1 Does the difference make the IP datagram more or less vulnerable to traffic analysis? Can a thirdparty observer learn more or less by observing an IPv6 traffic stream than he could learn observing the corresponding IPv4 traffic stream? 1 For a general overview of the use of IP fields as covert channels, see Covert Channels in the TCP/IP Suite. [1] Craig Partridge, Alfred W. Arsenault, and Stephen T. Kent BBN Technologies Cambridge. MA We emphasize that these questions are starting points. If we find an obvious IA issue that doesn't neatly fall into these categories, we examine it. So, for instance, we examine issues of IPv4 and IPv6 co-existing on the same network. B. A COMMENT ON IMPLEMENTATION ISSUES As Garfinkel points out in [2], implementation of IPv6 requires the development of substantial amounts of new hardware and software. History shows us repeatedly that all new hardware and software, no matter how carefully designed, analyzed and tested, will have some bugs. It is likely that some of these will manifest themselves as security vulnerabilities. Migration to IPv6 will have to deal with these, and be prepared to mitigate the bugs when they are found. At the same time, trying to predict where bugs might lie in an implementation is a highly speculative exercise. So, this paper does not talk much about possible implementation problems. II. IPV6 BASICS We start with an overview of what makes IPv6 different from IPv4. This discussion serves two purposes. First, it provides context as later sections consider IPv6 IA issues in various environments. Second, we can highlight some IA issues that arise simply as a consequence of IPv6 s differences from IPv4. A. DIFFERENCES BETWEEN IPV4 AND IPV6 As identified in RFC 2460[3], the primary differences between IPv4 and IPv6 include: (1) expanded addressing capabilities; (2) a simpler (but larger) header format; (3) a new way to handle options and extensions; (4) flow labeling; and (5) authentication and privacy We consider each of these changes. We look first at changes in the IPv6 base header, and then at changes in options and extensions caused by IPv6 s new way of handling options and extensions. B. BASE HEADER CHANGES 1. EXPANDED ADDRESSING CAPABILITIES The obvious issues in addressing come in two forms. First, the IPv6 addresses are much larger and the change in size makes a difference. The second issue is evaluating the IA implications of the new mix of addressing that IPv6 supports. IPv6 addresses are 128-bits long (16 bytes) versus IPv4 s 32-bit (4 byte) addresses. That difference in size raises a

2 number of issues. We consider them here in no particular order. One issue is that larger addresses make looking up an address more expensive in hardware and software that must process IP headers, e.g., routers, firewalls, and internet-layer crypto devices. Exactly how much more expensive depends on the context in which a lookup is being done. In a router, the lookup cost is typically about 40%-50% more expensive as the cost of lookups is logarithmic (so looking up twice as many bits adds only one more lookup) [4]. In devices that seek to do more sophisticated pattern matching, such as firewalls and security gateways, the lookup costs may be substantially higher. From a theoretical perspective, in a firewall, the search space grows as the square of the address size (because both source and destination addresses may be used to filter traffic). Pragmatically, we tend to restrict the filter space to avoid this kind of state space explosion, so the impact is likely to be less significant. However, it remains true that firewall and security gateway filters or rule sets will require more memory to support. Another issue with larger addresses is that they represent a larger potential information channel. Two examples illustrate this point. First, imagine the IP address fields as a covert channel. In IPv6, these fields represent 256 bits of information per packet sent, while in IPv4 the fields represent only 64 bits. The extent to which this covert channel is useful to an adversary will vary depending on the context in which the addresses are used; however, there is clearly much more for an attacker to work with in IPv6 addresses. The second example is more pragmatic. Some IPv6 address schemes assume that the low-order 8 bytes of the expanded IP address contain an IEEE EUI-64 MAC-layer identifier, which is typically taken from the network adapter chipset. IEEE EUI-64 identifiers are unique and are assigned to network adapter manufacturers as needed. Accordingly, if you know the EUI-64 identifier for a system, you can often make an educated guess about who manufactured the machine and what kind of system it is [5]. Having a user s system identified may be undesirable, especially if, for instance, the EUI-64 identifier can be used to identify hardware platforms with known or likely vulnerabilities [6], or to identify specialized equipment. (Note that, in IPv4, the EUI is not transmitted at the IP layer, so the degree of exposure of that information to adversaries presents less of a threat.) Thus this approach to assigning IPv6 addresses creates an OPSEC problem. Another problem is that the EUI-64 identifier can be used to trace a system as it moves from network to network[6] (e.g., a laptop that moves from a wired network to a wireless network). Pragmatically there s a solution: a proposed standard for using IPv6 with randomized identifiers for the low-order 8 bytes, described in RFC- 3041[6]. Of course, if the randomization is performed by untrusted software in a DHCP server, this represents another covert channel opportunity, one that might be difficult to monitor. Another approach to assigningipv6 addresses is described in RFC 3972[7], which calls for assigning these low order bits based on public key cryptographic mechanisms to improve security for mobile hosts. In addition to the difference in length, IPv6 has different types of addresses than IPv4. Some options for address assignment offer security benefits; others may result in new vulnerabilities. A clearly good change is that IPv6 has eliminated the concept of (scoped) broadcast addresses and replaced it with scoped multicast addresses. From a theoretical perspective, that s a good change, as it reduces the ability of systems to send unwanted traffic to all nodes on a network, an obvious DoS concern. From a practical perspective, the effect is small, as most firewalls and routers already refuse to forward most broadcast datagrams. A less clear change is the addition of anycast addresses. An anycast address is a way of advertising a service the idea is that any system that supports a particular service can join the anycast address and the network will route any datagrams addressed to the anycast address to the nearest participating system [8]. It is useful to contrast anycast with multicast for service location. A service can be provided by a multicast group. In that case, routers will send datagrams addressed to the multicast group to all servers that participate in the multicast group. This in itself is a DoS vulnerability, as it allows an attacker to send a few packets that will be replicated by routers (under some multicast implementation models) and delivered to a possibly large number of subscribers. Thus multicast represents a significant DoS concern, one that has not necessarily been improved by the transition from IPv4 to IPv6. Anycast is preferable to multicast from a DoS perspective, as it does not amplify traffic offered to the network. However, from an IA perspective, anycast often provides more information. In particular, if a server fails and it is part of a multicast group, we need not advertise that failure to the network datagrams addressed to the multicast group will be delivered to other servers in the multicast

3 group that can process those datagrams. In contrast, if a server fails and it is participating in an anycast address, we must inform the network that the server is no longer operational, as otherwise some datagrams will continue to be delivered to (but not served by) the server. Pragmatically, this is probably not a large IA issue. However, it does indicate the need to think about which services, especially battlefield services, use IPv6 anycast and which ones are supplied via IPv6 multicast. For instance, one might imagine that generic services (such as DNS servers) are advertised by anycast, because very little information is conveyed by an anycast address showing up, or going away. However, one might decide that command centers use multicast, as anything that might hint at how a command center is moving among networks is, probably, not information we want publicly visible. 2. SIMPLER BUT LARGER HEADER Because the IPv6 header contains substantially larger addresses, it is larger than the IPv4 header. But the IPv6 header actually supports fewer functions than IPv4. For example, options have been removed from the header and replaced by a nested-header approach that simplifies packet processing in routers. From an IA perspective, the most useful change is that IPv6 has eliminated fragmentation by intermediate nodes. Only the source may fragment an IPv6 datagram. That restriction reduces IA problems that are caused by fragmentation. For example, fragmentation by intermediate nodes provides yet another covert channel a router can signal information by fragmenting (or not) user traffic it processes. Since this would involve an attacker using traffic from another user to signal information, this would be a covert channel that would be very difficult to detect and close. 3. FLOW LABEL The flow label is the major new service in the IPv6 header. It is a 20-bit field, set by the sender, and used (in combination with the source address) as a short hand tag intended to make it easier for routers to identify and preferentially serve different traffic streams. An obvious potential security concern is that the flow label might be used as a covert channel (as its values are entirely at the discretion of the sender) across various boundary protection devices, e.g., IPsec Internet-layer crypto devices. This concern might be ameliorated by defining flow label creation rules and enforcing their use in a given system, to limit the resulting covert channel bandwidth. One should also explore the possibility that router code that examines and tracks flow labels may be vulnerable to various forms of denial or degradation of service attacks [2], since this code is relatively new and untested. For example, with a 20-bit field length, there are a million possible distinct flow labels, but a vendor may not have made provision to deal with this many labels simultaneously. C. OPTIONS AND EXTENSIONS In IPv4, most enhancements to IP service were implemented with options attached to the IP header. In IPv6, all options and enhancements are implemented through nested encapsulation, with each nesting having its own header. In principle, this nested header approach could enable better router and firewall processing of IPv6 header extensions (compared to options in IPv4). However, at least for the near term, it seems likely that the wide range of IPv6 header extensions and their nesting alternatives will result in increased opportunities for firewalls and routers to make errors in processing. The reasoning here is that developers have little or no experience in processing IPv6 headers, much less header extensions, and thus implementation errors are likely. In IPv4, option use is uncommon in practice 2. Routers direct IPv4 packets with options to management processors, out of fast path traffic flow. This provides a means of possibly overloading the management processors, which are also responsible for routing. Routers may be able to minimize the risk of this by rate limiting the slow path processing, since option use is so rare. However, if extension headers become commonly used in IPv6, this may affect router performance, as it might no longer be acceptable to treat packets containing extensions as second class citizens. Many firewalls are configured to discard IPv4 packets with options, or with certain classes of options. In the IPv4 context this rarely causes problems since options are rarely used. However, if extension headers are more commonly employed in the IPv6 context, this sort of behavior will not be acceptable. Thus firewalls will have to be prepared to examine these headers in more detail, and firewall configuration will become even more complex as a side 2 In large part this is because routers have long shunted any packets with options off the fast path, thus discouraging their use by hosts. It also was the case that network stacks often didn t offer an API to apps to invoke some of these options. We note that the same fate may await some IPv6 extension headers as well. Hosts must have network stack (hence OS-supported) APIs to give applications the ability to request extensions. Application writers have to make use of the extensions, via the APIs. Routers must not discriminate against hop-by-hop extensions (except where they require non-trivial router processing). Unless all of these are met, an IPv6 extension is not likely to be used in practice.

4 effect. This will likely result in more configurationinduced vulnerabilities in firewalls. Since many firewalls are not configured to tightly constrain outbound traffic, the presence of extension headers offers more opportunities to exfiltrate data from enclaves. Similar concerns arise in the context of IPsec, re covert channel opportunities, although use of ESP in tunnel mode will lessen the covert channel concerns because it will make the headers not visible to firewalls. Per RFC 2460, the following extension headers must be supported by a conforming IPv6 implementation: Hop-by- Hop Options; Routing (Type 0); Fragment; Destination Options; Authentication and Encapsulating Security Payload. We address each of these header types and its IA implications in turn. 1. HOP-BY-HOP OPTIONS The only two hop-by-hop options defined in RFC-2460 are Pad1 (add one octet of padding to an options header) and PadN (add N >1 octet of padding to an options header). Neither of these appears to have a serious IA impact. It may be possible to use the PadN option to achieve a covert channel by using more padding than is required to pad to the appropriate byte boundary. However such excess padding is easily detected and the potential channel data rate is quite modest, so this threat seems small. Another hop-by-hop option, the router alert option, is defined by RFC-2711[9]. This option alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. For example, protocols such as RSVP use control datagrams that, while addressed to a particular destination, contain information that needs to be examined, and in some cases updated, by routers along the path between the source and destination. It is desirable to forward regular datagrams as rapidly as possible, while ensuring that the router processes these special control datagrams appropriately. The presence of the router alert option in an IPv6 datagram informs the router that the contents of this datagram are of interest to the router and to handle any control data accordingly. The absence of this option in an IPv6 datagram informs the router that the datagram does not contain information needed by the router and hence can be safely routed without further datagram parsing. The IA impact of this option is that any datagrams with it included will require the router to examine upper-layer contents of the datagram. Thus, it will increase the router s processing load, and could lead to denial of service attacks on routers. Designers will need to decide whether or not to support this option, and if so, to enable ISPs to rate limit its use at (specific) routers. 2. ROUTING The Routing header is used by an IPv6 source to list one or more intermediate nodes to be visited on the way to a packet's destination. Only the Type 0 routing header is defined in RFC The function provided by the routing header is very similar to IPv4's Loose Source and Record Route options. As such, the Routing header has significant security implications. If an attacker is familiar with the system topology, supporting the routing header might allow him to route around firewalls or security gateways. Additionally, this header can guarantee an attacker that IPv6 datagrams will be processed by specific routers, allowing those routers to be targeted by denial of service and distributed denial of service attacks. Biondi and Ebalard [10] recently showed how the Routing Header can be used to carry out advanced network discovery attacks, then to launch various Denial of Service attacks against specific nodes, even when those nodes are defended by the use of anycast. We generally recommend that the routing header NOT be supported, for these and related security reasons. 3. FRAGMENT As noted previously, IPv6 removes support for fragmentation of datagrams at intermediate nodes in the route. Datagrams can be fragmented only at the source node. A fragmenting source divides a datagram into fragments and then places each fragment into a complete IPv6 datagram, with a Fragment Header as an extension header after the IPv6 header. The Fragment header is patterned after the fragmentation fields in the IPv4 header and includes a fragmentation offset (13 bits) and fragmentation identifier (32 bits vs. IPv4 s 16 bits). Either the fragmentation offset or the fragmentation identifier, or both, can be used as covert channels. 4. DESTINATION OPTIONS The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s). The only destination options defined in RFC-2460 are the Pad1 and PadN options, described above. There are no significant IA implications of either of these options. 5. SECURITY EXTENSIONS The IPv6 specification requires that conforming implementations include extension headers to support the

5 IPsec Authentication Header (AH) and the Encapsulating Security Payload (ESP). These extension headers are actually distinct protocols, defined in a series of RFCs [11, 12, 13]. These protocols are already widely supported in the IPv4 context, so the mandated support for them in IPv6 does not represent a significant change from the IPv4 context. III. IPV6 SUPPORT PROTOCOLS An internet protocol requires a set of supporting protocols to perform functions such as address assignment, router discovery, and routing. As part of the transition to IPv6, the Internet standards community has chosen to reexamine the protocols used in IPv4 and, in some cases, replace them rather than simply extending them. We briefly consider the most notable changes here. A. NEIGHBOR DISCOVERY IPv4 has a suite of protocols to support the discovery of addresses and routers. IPv6 replaces these protocols with a single protocol called Neighbor Discovery[14]. The IPv6 Neighbor Discovery protocol corresponds to a combination of the IPv4 protocols ARP[15], ICMP Router Discovery[16], and ICMP Redirect[16]. The features of Neighbor Discovery are of key concern for IA, as they determine, in large part, how well any node is connected, and over which paths it sends its data. We discuss each mechanism in detail below. 1. ROUTER DISCOVERY Router discovery allows hosts to locate the routers on their local sub-network. Router discovery eliminates the need for hosts to snoop routing protocols (or use DHCP) to determine the first hop router address. This may improve a system s IA posture, as it limits the complex protocol interactions that sometimes lead to security vulnerabilities. 2. PREFIX DISCOVERY In IPv6, router advertisements carry prefixes for a link; there is no need to have a separate mechanism to configure the netmask, as is required for IPv4 networks. This lessens the chances of a configuration error introducing vulnerabilities into the network. Conversely, spoofed router advertisements accepted by local hosts could prevent communication by these hosts. If the hosts were properly, manually, configured; or configured via a properly-functioning DHCP implementation, they would have been able to communicate. 3. PARAMETER DISCOVERY IPv6 routers can advertise a Maximum Transmission Unit (MTU) for hosts to use on the link, ensuring that all nodes use the same MTU value on links lacking a well-defined MTU. This helps limit accidental DoS attacks caused by a mis-configured host repeatedly attempting to send datagrams larger than the path MTU, resulting in the repeated discarding of these datagrams. Here too, the potential of spoofed MTU advertisements would enable degradation of service attacks against hosts. Since IPv4 hosts can adjust MTU based on path measurements, it is not clear if the automated MTU configuration vulnerability represents a significant concern. 4. ADDRESS RESOLUTION An important part of routing is figuring out what link level address goes with a particular IPv6 address. In IPv4 networks, using the Address Resolution Protocol (ARP) typically solves this. In IPv6, router advertisements carry link-layer addresses. There is no ARP-equivalent for IPv6. This simplifies the overall system design. It eliminates the possibility of an attacker on the local link hijacking ARP responses to gain access to information. It limits denial of service attacks by limiting the possibility of ARP cache poisoning. Moreover, the cleaner and simpler design of IPv6 s approach helps to eliminate some of the complexities involved in having two protocols (IPv4 and ARP) being interdependent. Since ARP cache attacks have been a concern in many contexts, this represents a possibly significant IA improvement, if router advertisements can be authenticated. Significant work is now being done in the IETF s Secure Inter-Domain Routing (SIDR) Working Group on the authentication of router advertisements. [17] This work will result in the necessary infrastructure for public keybased authentication of router advertisements. Finally, placing address resolution at a higher layer makes the protocol more media-independent than ARP and makes it possible to use standard IP authentication and integrity mechanisms as appropriate. The major challenge here is managing cryptographic authentication data, so that hosts can verify the source of this traffic. 5. NEXT-HOP DETERMINATION Given a particular destination, to which router should a host send a datagram? The combination of router discovery and redirection provides this service. Section 8 discusses how IPv6 supports redirection. 6. NEIGHBOR DOWN/UNREACHABLE In IPv4 there is no generally agreed upon protocol or mechanism for Neighbor Unreachability Detection. In IPv6, neighbor unreachability detection is part of the base protocol suite. This significantly improves the robustness of packet delivery in the presence of failing or attacked routers, partially failing or partitioned links, and nodes that

6 change their link-layer addresses. For instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches. When a router or other node is under a denial of service attack, neighboring nodes can determine more easily that it is not responding or is responding slowly, and can more easily route around it. However, if authentication is not used, the neighbor down/unreachable protocol can be spoofed[18]. The neighbor down/unreachable protocol is executed when there is a sufficiently long delay receiving upper-layer traffic or when a node stops receiving replies from a peer. The node sends a Neighbor Solicitation (NS) message to the peer. If it does not receive a Neighbor Advertisement (NA) response in a specified time, the node deletes the peer s cache entry. If NS and NA messages are not authenticated, an attacker can spoof NA messages as if they were from the peer, and thus cause the node to consider the peer as still being reachable and keep trying to send traffic to it. This is a denial of service attack. 7. DUPLICATE ADDRESS DETECTION Two or more nodes on the same network using the same unicast internet address are usually the sign of a misconfigured host (or network). However, grabbing (falsely advertising) addresses (especially of servers) is also an effective denial of service attack or a means to cause traffic to be erroneously redirected. As a result, knowing when an address is being used by more than one node is an important function. The IETF has specified (in RFC- 2461[14]) that the Neighbor Discovery protocol is to be used to detect cases when an address is use by multiple nodes. The discovery mechanism is not secure, in the sense that it is still possible to capture a server s IP address. However it makes capture more difficult, and more likely to be swiftly discovered. There s a subtle IA issue. Strictly speaking, under RFC- 2461, a node is required to shut down use of an address that it discovers is in use by another node. If the node is hostile, presumably the node will not stop using the address rather it will be the properly operating node that shuts down. In some situations, that may not be the desired behavior. If a server s address is being stolen, if may be desirable for the server to stay up and fight to hold onto its address. While this is the standard behavior in IPv4, in IPv6 it can only be achieved if Neighbor Discovery uses IPsec authenticated datagrams. This will generally require the use of public key-based authentication (e.g., based on a PKI), as shared-secret based authentication will not scale well for large internets. 8. REDIRECTION Redirection is directing a host to a different router to provide a better path to a specified destination. In IPv4 networks, this is accomplished through ICMP redirect messages. In IPv6, redirects contain the link-layer address of the new first hop; separate address resolution is not needed upon receiving a redirect. Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases, hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate. Unlike IPv4, the recipient of an IPv6 redirect assumes that the new next-hop is on-link. In IPv4, a host ignores redirects specifying a next-hop that is not on-link according to the link's network mask. The IPv6 redirect mechanism is expected to be useful on non-broadcast and shared media links in which it is undesirable or not possible for nodes to know all prefixes for on-link destinations. As part of the Internet standards process, protocol specifications are required to consider security issues, and this specification has undergone an above average security analysis. The analysis points out that it is better than the corresponding IPv4 protocols and that, in IPv6, it is possible to set up a network where all Neighbor Discovery messages are authenticated using IPsec. The original Neighbor Discovery specification, however, required manual configuration of point-wise security associations between hosts and first-hop routers, which is impractical in large networks. This was corrected in RFC 3971[19], where extensions were added to Neighbor Discovery to make use of a Public Key Infrastructure that attests to the ownership of IP address blocks. Such a PKI is already under development in the IETF s SIDR working group[17]. B. ADDRESS ASSIGNMENT IPv6 supports two different modes of address assignment. One is stateless and uses information from Neighbor Discovery to allow each node to autonomously assign itself an address (the scheme is described in RFC 2462[20]). The other is stateful and uses the Dynamic Host Configuration Protocol (DHCP), modified for IPv6, described in RFC-3315[21]. Both address assignment schemes are known to be vulnerable to denial of service attacks in the absence of authenticated datagrams. So far, no study seems to have been performed on the co-existence of the two schemes

7 and which scheme might be preferred for system operation. IV. IPV6 AND IPV4 CO-EXISTENCE A key IA question is exactly how IPv6 and IPv4 will coexist on one network. There are many proposed approaches. The discussion in this section is motivated by a simple policy: we would expect that if an application or node cannot use a particular service or protocol under IPv4, it should not be able to do so under IPv6 (and vice-versa). Now this statement is clearly simplistic. There are situations where permitting a service to be run with only one protocol by not the other makes sense. But the policy is a useful starting assumption and clarifies many issues. A. Running IPv4 and IPv6 Side-by-Side One approach is to run a network in a dual mode, with routers supporting both IPv4 and IPv6. The challenge, then, is keeping the IPv4 and IPv6 domains consistent. In general, we would probably like to be sure that if we exclude IPv4 traffic from a particular site, e.g., via a firewall rule set, that we exclude IPv6 traffic from that site as well. Since the IPv4 and IPv6 address spaces are distinct, ensuring that kind of consistency is difficult. There will be routers and firewalls that block out the IPv4 space, but not the IPv6 space, or vice-versa. This problem is compounded by IPv4-IPv6 translation (see below). There is a need for tools or mechanisms that will keep IPv4 and IPv6 devices consistent. B. IPv4-IPv6 Translation IPv4-IPv6 translation relies on the existence of special gateways that convert IPv4 datagrams to IPv6 datagrams and vice-versa. The appeal of translation is that it eases service availability issues. Translation allows a new IPv6 device to reach an existing IPv4 service. Translation is an IA headache. It effectively creates a backdoor, in that IPv6 traffic that would be blocked could be converted by a translator into IPv4 traffic that would be accepted. This could occur because of inconsistent firewall and filtering rules as noted above, or simply because while an IPv6 device sits in a banned address space, the translator sits in an unrestricted IPv4 space and thus converts the banned IPv6 address into an acceptable IPv4 address. C. Handling IPv6 Islands During a transition period, there will likely be islands of IPv6 networks within a larger IPv4 network. There are a number of schemes to support IPv6 islands. Here we briefly discuss two approaches, 6to4 and Teredo, to illustrate some of the issues. 6to4 is an elegant and very simple way to connect IPv6 islands across an IPv4 backbone. The basic idea is that each IPv6 island has a specific IPv4 router that connects the IPv6 island to the larger IPv4 network. The key trick is to embed the 32-bit IPv4 address of this router into some of the bits of the IPv6 address. The elegance of 6to4 is that IPv6 routing is naturally piggybacked on the existing IPv4 routing. From an IA perspective, the fact that the IPv4 and IPv6 addresses are from the same space may encourage consistent treatment of IPv4 and IPv6 traffic. However, the simplicity of 6to4 means that it is trivial for an IPv6 device to send traffic to any IPv4 device and it is equally trivial for any IPv4 device to tunnel datagrams into an IPv6 enclave. The dangers of the IPv6-to-IPv4 traffic are minimal, as all datagrams will take the form of IPv6 datagrams embedded in IPv4 datagrams and thus if the receiving does not support IPv6, the datagram is largely harmless. But the IPv4-to-IPv6 attack is more serious any IPv4 device can introduce any IPv6 datagram it desires into the IPv6 island. Teredo is an IPv6 tunneling approach developed by Microsoft. The goal of Teredo is to support 6to4-style service in networks that do not have the resources to place a dedicated 6to4 router at their edge and, indeed, may be behind IPv4 NAT boxes. To avoid problems with NAT boxes, Teredo places IPv6 datagrams inside UDP datagrams. And, to avoid the need for an IPv6 router, it enables any host to become an IPv6 router. Pragmatically, Teredo s IA issues are largely the same as 6to4, with the added complication that any device can now act as a router. The ability to make hosts into routers at will is an administrative nightmare, as each new host added to a network implies the appearance of a new IPv6 router that must be configured according to local IA practices. V. CONCLUSIONS In general, IPv6 appears to be somewhat better than IPv4 at addressing several IA issues. Our analysis suggests there will have to be a set of IA protocol profiles that enumerate how IPv6 and its supporting protocols should be used. While initial drafts of some of these profiles could be written now, the final form of each of these profiles will depend on the completion of additional studies.

8 VI. REFERENCES [1] M. Kang, I. Moskowitz, and D. Lee, A network version of the pump. Proc. IEEE Symp. Security and Privacy, pp , May [2] S. Garfinkel, Internet 6.0, Technology Review, MIT Press, January [3] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998 [4] M. Waldvogel, G. Varghese, J. Turner and B. Plattner, Scalable High Speed IP Routing Lookups, Proc. ACM SIGCOMM '97, Cannes France, September [5] IEEE publishes a table mapping from OUI (first part of EUI) to manufacturer. [6] T. Narten, and R. Draves, Privacy Extensions for Stateless Address Auto-configuration in IPv6, RFC 3041, January 2001 [7] T. Aura, Cryptographically Generated Addresses (CGA), RFC 3972, March [8] C. Partridge, T. Mendez, and W. Milliken. Host Anycasting Service, RFC 1546, November [9] C. Partridge and A. Jackson, IPv6 Router Alert Option, RFC-2711, October 1999 [10] P. Biondi and A. Ebalard, Fun with IPv6 Routing Headers, Proc. CanSecWest 2007, Vancouver, CA, April 2007 [11] S. Kent, K. Seo, Security Architecture for the Internet Protocol, RFC 4301, December 2005 [12] S. Kent, IP Authentication Header, RFC 4302, December 2005 [13] S. Kent, IP Encapsulating Security Payload (ESP), RFC 4303, December 2005 [14] T. Narten, E. Nordmark, and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December 1998 [15] D. Plummer, An Ethernet Address Resolution Protocol -- or --Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware, RFC 826, November 1982 [16] J. Postel, Internet Control Message Protocol, RFC 792, September 1981 [17] M. Lepinski, S. Kent, and R. Barnes, An Infrastructure to Support Secure Internet Routing, Internet Draft draft-ietf-sidr-arch-01.txt, 8 July 2007 [18] P. Nikander, J. Kempf, E. Nordmark, IPv6 Neighbor Discovery (ND) Trust Models and Threats, RFC 3756, May [19] J. Arkko, J. Kempf, B. Zill, and P. Nikander, Secure Neighbor Discovery Protocol (SEND), RFC 3971, March [20] S. Thomson and T. Narten, IPv6 Stateless Address Autoconfiguration, RFC 2462, December 1998 [21] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC-3315, July 2003