idnits 2.17.1 draft-gont-6man-nd-extension-headers-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2011) is 4699 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-gont-v6ops-ra-guard-evasion-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft UK CPNI 4 Updates: 4861 (if approved) June 8, 2011 5 Intended status: Standards Track 6 Expires: December 10, 2011 8 Security Implications of the Use of IPv6 Extension Headers with IPv6 9 Neighbor Discovery 10 draft-gont-6man-nd-extension-headers-01 12 Abstract 14 IPv6 Extension Headers with Neighbor Discovery messages can be 15 leveraged to circumvent simple local network protections, such as 16 "Router Advertisement Guard". Since there is no legitimate use for 17 IPv6 Extension Headers in Neighbor Discovery messages, and such use 18 greatly complicates network monitoring and simple security 19 mitigations such as RA-Guard, this document proposes that hosts 20 silently ignore Neighbor Discovery messages that use IPv6 Extension 21 Headers. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, and it may not be 28 published except as an Internet-Draft. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 10, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Changes from previous versions of the draft (to 67 be removed by the RFC Editor before publication 68 of this document as a RFC . . . . . . . . . . . . . . 8 69 A.1. Changes from draft-gont-6man-nd-extension-headers-00 . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique 75 for attack vectors based on ICMPv6 Router Advertisement messages. 76 [RFC6104] describes the problem statement of "Rogue IPv6 Router 77 Advertisements", and [RFC6105] specifies the "IPv6 Router 78 Advertisement Guard" functionality. 80 [I-D.gont-v6ops-ra-guard-evasion] describes how IPv6 Extension 81 Headers can be leveraged to circumvent the RA-Guard protection. 82 Additionally, the use of Extension Headers (and of the Fragmentation 83 Header in particularly) greatly increases the difficulty to monitor 84 Neighbor Discovery traffic (e.g., with tools such as NDPMon 85 [NDPMon]). 87 Since there is no current legitimate use for IPv6 Extension Headers 88 in IPv6 Neighbor Discovery packets, and avoiding their use in such 89 packets would greatly simplify the monitoring and mitigation of 90 Neighbor Discovery attacks, this document proposes that hosts 91 silently ignore Neighbor Discovery messages that employ IPv6 92 Extension Headers. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Specification 100 Hosts SHOULD silently ignore Neighbor Discovery messages (Neighbor 101 Solicitation, Neighbor Advertisement, Router Solcicitation, and 102 Router Advertisement messages) that employ IPv6 Extension Headers. 104 3. Security Considerations 106 IPv6 Extension Headers can be leveraged to circumvent network 107 monitoring and mechanisms such as RA-Guard 108 [I-D.gont-v6ops-ra-guard-evasion]. By updating the relevant 109 specifications such that IPv6 Extension Headers are not allowed in 110 Neighbor Discovery messages, protection of local network against 111 Neighbor Discovery attacks, and monitoring of Neighbor Discovery 112 traffic is greatly simplified. 114 [I-D.gont-v6ops-ra-guard-evasion] discusses an improvement to the RA- 115 Guard mechanism that can mitigate Neighbor Discovery attacks that 116 employ IPv6 Extension Headers. However, it should be noted that 117 unless [RFC4861] is updated (as proposed in this document) such that 118 use of IPv6 extension headers is not allowed with Neighbor Discovery 119 messages, monitoring of Neighbor Discovery traffic and mitigation of 120 Neighbor Discovery vulnerabilities will probably imply increased 121 complexity and/or reduced performance in the corresponding devices 122 (RA-Guard box, Network Intrusion Detection Systems, etc.). 124 4. Acknowledgements 126 The author would like to thank Arturo Servin for providing valuable 127 comments on earlier versions of this document. 129 This document resulted from the project "Security Assessment of the 130 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by 131 Fernando Gont on behalf of the UK Centre for the Protection of 132 National Infrastructure (CPNI). The author would like to thank the 133 UK CPNI, for their continued support. 135 5. References 137 5.1. Normative References 139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 140 Requirement Levels", BCP 14, RFC 2119, March 1997. 142 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 143 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 144 September 2007. 146 5.2. Informative References 148 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 149 Problem Statement", RFC 6104, February 2011. 151 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 152 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 153 February 2011. 155 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", 156 . 158 [I-D.gont-v6ops-ra-guard-evasion] 159 Gont, F. and U. CPNI, "IPv6 Router Advertisement Guard 160 (RA-Guard) Evasion", draft-gont-v6ops-ra-guard-evasion-00 161 (work in progress), May 2011. 163 [CPNI-IPv6] 164 Gont, F., "Security Assessment of the Internet Protocol 165 version 6 (IPv6)", UK Centre for the Protection of 166 National Infrastructure, (to be published). 168 Appendix A. Changes from previous versions of the draft (to be removed 169 by the RFC Editor before publication of this document as a 170 RFC 172 A.1. Changes from draft-gont-6man-nd-extension-headers-00 174 o The Security Considerations section now notes that unless IPv6 175 extension headers are not allowed with Neighbor Discovery 176 messages, monitoring ND traffic and/or mitigating ND 177 vulnerabilities might result in increased complexity and/or 178 reduced performance. 180 o Minor editorial changes 182 Author's Address 184 Fernando Gont 185 Centre for the Protection of National Infrastructure 187 Email: fernando@gont.com.ar 188 URI: http://www.gont.com.ar