--- 1/draft-ietf-v6ops-ra-guard-implementation-01.txt 2012-03-08 21:13:56.466671468 +0100 +++ 2/draft-ietf-v6ops-ra-guard-implementation-02.txt 2012-03-08 21:13:56.494670885 +0100 @@ -1,18 +1,18 @@ IPv6 Operations Working Group (v6ops) F. Gont Internet-Draft UK CPNI -Intended status: BCP March 3, 2012 -Expires: September 4, 2012 +Intended status: BCP March 8, 2012 +Expires: September 9, 2012 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) - draft-ietf-v6ops-ra-guard-implementation-01 + draft-ietf-v6ops-ra-guard-implementation-02 Abstract The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." - This Internet-Draft will expire on September 4, 2012. + This Internet-Draft will expire on September 9, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -281,24 +281,31 @@ follow the IPv6 header chain, enforcing a limit on the maximum number of Extension Headers that is allowed for each packet. If such limit is hit before the upper-layer protocol is identified, silently drop the packet. 2. If the packet is identified to be an ICMPv6 Router Advertisement message, silently drop the packet. 3. If the layer-2 device is unable to identify whether the packet is an ICMPv6 Router Advertisement message or not (i.e., the packet - is a fragment, and the necessary information is missing), the - IPv6 Source Address of the packet is a link-local address or the - unspecified address (::), and the Hop Limit is 255, silently drop - the packet. + is a first-fragment, and the necessary information is missing), + the IPv6 Source Address of the packet is a link-local address or + the unspecified address (::), and the Hop Limit is 255, silently + drop the packet. + + Note: This rule should only be applied to non-fragmented IPv6 + datagrams and IPv6 fragments with a Fragment Offset of 0 (non- + first fragments can be safely passed, since they will never + reassemble into a complete datagram if they are part of a + Router Advertisement received on a port where such packets are + not allowed). 4. In all other cases, pass the packet as usual. Note: For the purpose of enforcing the RA-Guard filtering policy, an ESP header [RFC4303] should be considered to be an "upper-layer protocol" (that is, it should be considered the last header in the IPv6 header chain). This means that packets employing ESP would be passed by the RA-Guard device to the intended destination. If the destination host does not have a security association with the sender of the aforementioned IPv6 packet, the packet would be @@ -342,39 +349,56 @@ A similar concept to that of "RA-Guard" has been implemented for protecting against forged DHCPv6 messages. Such protection can be circumvented with the same techniques discussed in this document, and the counter-measures for such evasion attack are analogous to those described in Section 3 of this document. 5. Security Considerations This document describes a number of techniques that have been found - to be effective to circumvent popular RA-Guard implementations. + to be effective to circumvent popular RA-Guard implementations, and + provides advice to RA-Guard implementations such that those evasion + vulnerabilities are eliminated. - The most effective and efficient mitigation for these attacks would - be to prohibit the use of some IPv6 extension headers with Router - Advertisement messages (as proposed by + We note that if an attacker sends a fragmented Router Advertisement + message on a port not allowed to send such packets, the first- + fragment would be dropped, and the rest of the fragments would be + passed. This means that the victim node would tie memory buffers for + the aforementioned fragments, which would never reassemble into a + complete datagram. If a large number of such packets were sent by an + attacker, and the victim node failed to implement proper resource + management for the fragment reassembly buffer, this could lead to a + Denial of Service (DoS). However, this does not really introduce a + new attack vector, since an attacker could always perform the same + attack by sending forged fragmented datagram in which at least one of + the fragments is missing. [CPNI-IPv6] discusses some resource + management strategies that could be implemented for the fragment + reassembly buffer. + + Finally, we note that most effective and efficient mitigation for + these attacks would be to prohibit the use of IPv6 fragmentation with + Router Advertisement messages (as proposed by [I-D.gont-6man-nd-extension-headers]), such that the RA-Guard functionality is easier to implement. However, since such mitigation would require an update to existing implementations, it cannot be relied upon in the short or near term. 6. Acknowledgements The author would like to thank Ran Atkinson, Karl Auer, Robert - Downie, David Farmer, Marc Heuse, Ray Hunter, Simon Perreault, Arturo - Servin, and Gunter van de Velde, for providing valuable comments on - earlier versions of this document. + Downie, Washam Fan, David Farmer, Marc Heuse, Ray Hunter, Simon + Perreault, Arturo Servin, and Gunter van de Velde, for providing + valuable comments on earlier versions of this document. - The author would like to thank Arturo Servin, who presented this work - at IETF 81. + The author would like to thank Arturo Servin, who presented this + document at IETF 81. This document resulted from the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). The author would like to thank the UK CPNI, for their continued support. 7. References 7.1. Normative References