idnits 2.17.1 draft-gont-6man-nd-extension-headers-00.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 (May 31, 2011) is 4707 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) == Unused Reference: 'RFC4861' is defined on line 128, but no explicit reference was found in the text == Unused Reference: 'RFC6104' is defined on line 134, but no explicit reference was found in the text == Unused Reference: 'RFC6105' is defined on line 137, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 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) May 31, 2011 5 Intended status: Standards Track 6 Expires: December 2, 2011 8 Security Implications of the Use of IPv6 Extension Headers with IPv6 9 Neighbor Discovery 10 draft-gont-6man-nd-extension-headers-00 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 2, 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique 71 for attack vectors based on ICMPv6 Router Advertisement messages. 72 describes the problem statement of "Rogue IPv6 Router 73 Advertisements", and specifies the "IPv6 Router Advertisement Guard" 74 functionality. 76 [draft-gont-v6ops-ra-guard-evasion] describes how IPv6 Extension 77 Headers can be leveraged to circumvent the RA-Guard protection. 78 Additionally, the use of Extension Headers (and of the Fragmentation 79 Header in particularly) greatly increases the difficulty to monitor 80 Neighbor Discovery traffic (e.g., with tools such as NDPMon). 82 Since there is no current legitimate use for IPv6 Extension Headers 83 in IPv6 Neighbor Discovery packets, and since avoiding their use for 84 such packets greatly simplifies monitoring of Neighbor Discovery 85 traffic and the possible mitigations for Neighbor Discovery attacks, 86 this document proposes that hosts silently ignore Neighbor Discovery 87 messages that employ IPv6 Extension Headers. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. Specification 95 Hosts SHOULD silently ignore Neighbor Discovery messages (Neighbor 96 Solicitation, Neighbor Advertisement, Router Solcicitation, and 97 Router Advertisement messages) that employ IPv6 Extension Headers. 99 3. Security Considerations 101 IPv6 Extension Headers can be leveraged to circumvent network 102 monitoring and mechanisms such as RA-Guard 103 [draft-gont-v6ops-ra-guard-evasion]. By updating the relevant 104 specifications such that IPv6 Extension Headers are not allowed in 105 Neighbor Discovery messages, protection of local network against 106 Neighbor Discovery attacks, and monitoring of Neighbor Discovery 107 traffic is greatly simplified. 109 [draft-gont-v6ops-ra-guard-evasion] discusses possible filtering 110 rules that could be enforced to mitigate Neighbor Discovery attacks 111 that employ IPv6 Extension Headers. 113 4. Acknowledgements 115 This document resulted from the project "Security Assessment of the 116 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by 117 Fernando Gont on behalf of the UK Centre for the Protection of 118 National Infrastructure (CPNI). The author would like to thank the 119 UK CPNI, for their continued support. 121 5. References 123 5.1. Normative References 125 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 126 Requirement Levels", BCP 14, RFC 2119, March 1997. 128 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 129 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 130 September 2007. 132 5.2. Informative References 134 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 135 Problem Statement", RFC 6104, February 2011. 137 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 138 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 139 February 2011. 141 [draft-gont-v6ops-ra-guard-evasion] 142 Gont, F., "IPv6 Router Advertisement Guard (RA Guard) 143 Evasion", IETF Internet Draft, 144 draft-gont-v6ops-ra-guard-evasion, work in progress, 145 May 2011. 147 [CPNI-IPv6] 148 Gont, F., "Security Assessment of the Internet Protocol 149 version 6 (IPv6)", UK Centre for the Protection of 150 National Infrastructure, (to be published). 152 Author's Address 154 Fernando Gont 155 Centre for the Protection of National Infrastructure 157 Email: fernando@gont.com.ar 158 URI: http://www.gont.com.ar