--- 1/draft-ietf-v6ops-security-overview-05.txt 2006-10-27 22:12:20.000000000 +0200 +++ 2/draft-ietf-v6ops-security-overview-06.txt 2006-10-27 22:12:20.000000000 +0200 @@ -1,21 +1,21 @@ IPv6 Operations E. Davies Internet-Draft Consultant Intended status: Informational S. Krishnan -Expires: March 4, 2007 Ericsson +Expires: April 25, 2007 Ericsson P. Savola CSC/Funet - August 31, 2006 + October 22, 2006 IPv6 Transition/Co-existence Security Considerations - draft-ietf-v6ops-security-overview-05.txt + draft-ietf-v6ops-security-overview-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -26,21 +26,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 4, 2007. + This Internet-Draft will expire on April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the @@ -56,57 +56,56 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4 2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 5 2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6 2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 7 2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7 2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8 2.1.6. Anycast Traffic Identification and Security . . . . . 9 2.1.7. Address Privacy Extensions Interact with DDoS - Defenses . . . . . . . . . . . . . . . . . . . . . . . 9 + Defenses . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy Extensions and SEND . . . . . . . . . . . . . 10 2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11 2.1.10. Fragmentation: Reassembly and Deep Packet Inspection . . . . . . . . . . . . . . . . . . . . . . 14 2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15 2.1.12. Link-Local Addresses and Securing Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 15 2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17 - 2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 17 + 2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 18 2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18 2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 18 2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20 2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20 2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 20 2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 22 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 22 3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 - Network Security Assumptions . . . . . . . . . . . . . . . 23 + Network Security Assumptions . . . . . . . . . . . . . . . 24 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 25 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 25 4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 27 4.3. Addressing Schemes and Securing Routers . . . . . . . . . 27 4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 27 4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 28 4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 29 4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 29 4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 30 4.8. Operational Factors when Enabling IPv6 in the Network . . 30 - 4.9. Ingress Filtering Issues Due to Privacy Addresses . . . . 31 - 4.10. Security Issues Due to Neighbor Discovery Proxies . . . . 31 + 4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 36 Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 37 B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 37 B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 38 B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 40 @@ -196,36 +195,41 @@ enabled. The Requirements for Internet Hosts [RFC1122] permits implementations to perform "local source routing", that is forwarding a packet with a routing header through the same interface on which it was received: no restrictions are placed on this operation even on hosts. In combination, these rules can result in hosts forwarding received traffic to another node if there are segments left in the Routing Header when it arrives at the host. A number of potential security issues associated with this behavior have been identified. Some of these issues have been resolved (a - separate routing header (Type 2) is now used for Mobile IPv6 - [RFC3775] and ICMP Traceback has not been standardized), but two + separate routing header (Type 2) has been standardized for Mobile + IPv6 [RFC3775] and ICMP Traceback has not been standardized), but two issues remain: - o Routing headers can be used to evade access controls based on - destination addresses. This could be achieved by sending a packet - ostensibly to a publicly accessible host address but with a - routing header containing a 'forbidden' address. If the publicly - accessible host is processing routing headers it will forward the - packet to the destination address in the routing header that would - have been forbidden by the packet filters if the address had been - in the destination field when the packet was checked. - o If the packet source address in the previous case can be spoofed, - any host could be used to mediate an anonymous reflection denial- - of-service attack by having any publicly accessible host redirect - the attack packets. + o Both existing types of routing header can be used to evade access + controls based on destination addresses. This could be achieved + by sending a packet ostensibly to a publicly accessible host + address but with a routing header containing a 'forbidden' + address. If the publicly accessible host is processing routing + headers it will forward the packet to the destination address in + the routing header that would have been forbidden by the packet + filters if the address had been in the destination field when the + packet was checked. + o If the packet source address can be spoofed when using a Type 0 + routing header, the mechanism described in the previous bullet + could be used with any host to mediate an anonymous reflection + denial-of-service attack by having any publicly accessible host + redirect the attack packets. (This attack cannot use Type 2 + routing headers because the packet cannot be forwarded outside the + host that processes the routing header, i.e., the original + destination of the packet.) To counteract these threats, if a device is enforcing access controls based on destination addresses, it needs to examine both the destination address in the base IPv6 header and any waypoint destinations in a routing header that have not yet been reached by the packet at the point where it is being checked. Various forms of amplification attack on routers and firewalls using the routing header could be envisaged. A simple form involves repeating the address of a waypoint several times in the routing header. More complex forms could involve alternating waypoint @@ -397,32 +401,34 @@ The purpose of the privacy extensions for stateless address auto- configuration [I-D.ietf-ipv6-privacy-addrs-v2] is to change the interface identifier (and hence the global scope addresses generated from it) from time to time. By varying the addresses used, eavesdroppers and other information collectors find it more difficult to identify which transactions actually relate to a specific node. A security issue may result from this if the frequency of node address change is sufficiently great to achieve the intended aim of the privacy extensions: with a relatively high rate of change, the - observed behavior of the node could look very like that of a - compromised node that was the source of a Distributed Denial-of- - Service (DDoS) attack. It would thus be difficult for any future - defenses against DDoS attacks to distinguish between a high rate of - change of addresses resulting from genuine use of the privacy - extensions and a compromised node being used as the source of a DDoS - with 'in-prefix' spoofed source addresses as described in - [I-D.ietf-ipv6-privacy-addrs-v2]. + observed behavior has some characteristics of a node or nodes + involved in a Distributed Denial-of-Service (DDoS) attack. It should + be noted, however, that addresses created in this way are + topologically correct and that the other characteristics of the + traffic may reveal that there is no malicious intent. - Even if a node is well behaved, the change in the address could make - it harder for a security administrator to define a policy rule (e.g., - access control list) that takes into account a specific node. + This issue can be addressed in most cases by tuning the rate of + change in an appropriate manner. + + Note that even if a node is well behaved, a change in the address + could make it harder for a security administrator to define an + address-based policy rule (e.g., access control list). However, + nodes that employ privacy addresses do not have to use them for all + communications. 2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy Extensions and SEND The introduction of Stateless Address Auto-Configuration (SLAAC) [RFC2462] with IPv6 provides an additional challenge to the security of Dynamic Domain Name System (DDNS). With manual addressing or the use of DHCP, the number of security associations that need to be maintained to secure access to the Domain Name Service (DNS) server is limited, assuming any necessary updates are carried out by the @@ -1402,36 +1410,21 @@ Many operator networks have to run interior routing protocols for both IPv4 and IPv6. It is possible to run the both in one routing protocol, or have two separate routing protocols; either approach has its tradeoffs [RFC4029]. If multiple routing protocols are used, one should note that this causes double the amount of processing when links flap or recalculation is otherwise needed -- which might more easily overload the router's CPU, causing slightly slower convergence time. -4.9. Ingress Filtering Issues Due to Privacy Addresses - - [I-D.ietf-ipv6-privacy-addrs-v2] describes a method for creating - temporary addresses on IPv6 nodes to address privacy issues created - by the use of a constant identifier. In a large network implementing - such a mechanism new temporary addresses may be created at a fairly - high rate. As discussed in Section 2.1.7, this might make it hard - for ingress filtering mechanisms to distinguish between legitimately - changing temporary addresses and spoofed source addresses, which are - "in-prefix" (i.e., they use a topologically correct prefix and non- - existent interface ID). This can be addressed by using finer grained - access control mechanisms on a per address basis at the network - egress point as suggested in the Security Considerations section of - [I-D.ietf-ipv6-privacy-addrs-v2]. - -4.10. Security Issues Due to Neighbor Discovery Proxies +4.9. Security Issues Due to Neighbor Discovery Proxies In order to span a single subnet over multiple physical links, a new experimental capability is being trialled in IPv6 to proxy Neighbor Discovery messages. A node with this capability will be called an NDProxy (see [RFC4389]. NDProxies are susceptible to the same security issues as the ones faced by hosts using unsecured Neighbor Discovery or ARP. These proxies may process unsecured messages, and update the neighbor cache as a result of such processing, thus allowing a malicious node to divert or hijack traffic. This may undermine the advantages of using SEND [RFC3971]. @@ -1474,22 +1467,22 @@ the issues with the base IPv6 specification which are documented here. 8. References 8.1. Normative References [I-D.ietf-ipv6-privacy-addrs-v2] Narten, T., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", - draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), - December 2005. + draft-ietf-ipv6-privacy-addrs-v2-05 (work in progress), + October 2006. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. @@ -1542,22 +1535,22 @@ draft-ietf-tcpm-icmp-attacks-00 (work in progress), February 2006. [I-D.ietf-v6ops-icmpv6-filtering-recs] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in progress), July 2006. [I-D.ietf-v6ops-nap] - Velde, G., "IPv6 Network Architecture Protection", - draft-ietf-v6ops-nap-03 (work in progress), July 2006. + Velde, G., "Network Architecture Protection for IPv6", + draft-ietf-v6ops-nap-04 (work in progress), October 2006. [I-D.ietf-v6ops-natpt-to-exprmntl] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work in progress), October 2005. [I-D.ietf-v6ops-scanning-implications] Chown, T., "IPv6 Implications for Network Scanning", draft-ietf-v6ops-scanning-implications-00 (work in progress), June 2006.