--- 1/draft-ietf-6man-nd-extension-headers-01.txt 2012-12-10 08:48:18.585390787 +0100 +++ 2/draft-ietf-6man-nd-extension-headers-02.txt 2012-12-10 08:48:18.601390248 +0100 @@ -1,19 +1,19 @@ IPv6 maintenance Working Group (6man) F. Gont Internet-Draft SI6 Networks / UTN-FRH -Updates: 3971, 4861 (if approved) November 5, 2012 +Updates: 3971, 4861 (if approved) December 10, 2012 Intended status: Standards Track -Expires: May 9, 2013 +Expires: June 13, 2013 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery - draft-ietf-6man-nd-extension-headers-01 + draft-ietf-6man-nd-extension-headers-02 Abstract This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971 @@ -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 May 9, 2013. + This Internet-Draft will expire on June 13, 2013. 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 @@ -51,26 +51,27 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Traditional Neighbor Discovery and IPv6 Fragmentation . . . . 5 3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation . . . 6 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Neighbor Discovery Protocol (NDP) is specified in RFC 4861 [RFC4861] and RFC 4862 [RFC4862]. It is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection. @@ -243,21 +244,27 @@ o Certification Path Solicitation Nodes SHOULD normally process the following messages when the packets carrying them include an IPv6 Fragmentation Header: o Certification Path Advertisement SEND nodes SHOULD NOT employ keys that would result in fragmented CPA messages. -5. Security Considerations +5. IANA Considerations + + There are no IANA registries within this document. The RFC-Editor + can remove this section before publication of this document as an + RFC. + +6. Security Considerations The IPv6 Fragmentation Header can be leveraged to circumvent network monitoring tools and current implementations of mechanisms such as RA-Guard [I-D.ietf-v6ops-ra-guard-implementation]. By updating the relevant specifications such that the IPv6 Fragment Header is not allowed in any Neighbor Discovery messages except "Certification Path Advertisement", protection of local nodes against Neighbor Discovery attacks, and monitoring of Neighbor Discovery traffic is greatly simplified. @@ -267,74 +274,74 @@ unless [RFC4861] is updated (as proposed in this document), Neighbor Discovery monitoring tools (such as NDPMon [NDPMon]) would remain unreliable and trivial to circumvent by a skilled attacker. As noted in Section 3, use of SEND could potentially result in fragmented "Certification Path Advertisement" messages, thus allowing an attacker to employ IPv6 fragmentation-based attacks against such messages. Therefore, to the extent that is possible, such use of fragmentation should be avoided. -6. Acknowledgements +7. Acknowledgements The author would like to thank (in alphabetical order) Mikael Abrahamsson, Ran Atkinson, Ron Bonica, Jean-Michel Combes, David Farmer, Roque Gagliano, Bob Hinden, Philip Homburg, Ray Hunter, Arturo Servin, and Mark Smith, for providing valuable comments on earlier versions of this document. 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 +8. References -7.1. Normative References +8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. -7.2. Informative References +8.2. Informative References [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", . [ramond] "ramond", . [I-D.ietf-v6ops-ra-guard-implementation] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", - draft-ietf-v6ops-ra-guard-implementation-05 (work in - progress), October 2012. + draft-ietf-v6ops-ra-guard-implementation-07 (work in + progress), November 2012. [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). [Gont-DEEPSEC2011] Gont, "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011,