idnits 2.17.1 draft-baker-6man-hbh-header-handling-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document updates RFC2460, but the abstract doesn't seem to directly say this. It does mention RFC2460 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- 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 6, 2015) is 3240 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-ietf-v6ops-ipv6-ehs-in-real-world-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance F. Baker 3 Internet-Draft Cisco Systems 4 Updates: 2460,7045 (if approved) June 6, 2015 5 Intended status: Standards Track 6 Expires: December 8, 2015 8 IPv6 Hop-by-Hop Header Handling 9 draft-baker-6man-hbh-header-handling-01 11 Abstract 13 This note updates the IPv6 Specification (RFC 2460), specifically 14 commenting on the Hop-by-Hop Options Header (section 4.3) and option 15 format and handling (section 4.2). 17 It also updates RFC 7045, which noted that RFC 2460 is widely 18 violated in this respect, but merely legitimized this situation with 19 a SHOULD. The present document tries to address the issue more 20 fundamentally. 22 It tries to address the issue. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 8, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Handling of options in extension headers . . . . . . . . . . 3 61 2.1. Hop-by_hop Options . . . . . . . . . . . . . . . . . . . 3 62 2.2. Changing options in transit . . . . . . . . . . . . . . . 4 63 2.3. Adding headers or options in transit . . . . . . . . . . 4 64 2.4. Interactions with the Security Extension Header . . . . . 4 65 3. Interoperation with RFC 2460 . . . . . . . . . . . . . . . . 5 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 The IPv6 Specification [RFC2460] specifies a number of extension 79 headers. These, and the ordering considerations given, were defined 80 based on experience with IPv4 options. They were, however, prescient 81 with respect to their actual use - the IETF community did not know 82 how they would be used. In at least one case, the Hop-by-Hop option, 83 most if not all implementations implement it by punting to a software 84 path. In the words of [RFC7045], 86 The IPv6 Hop-by-Hop Options header SHOULD be processed by 87 intermediate forwarding nodes as described in [RFC2460]. However, 88 it is to be expected that high-performance routers will either 89 ignore it or assign packets containing it to a slow processing 90 path. Designers planning to use a Hop-by-Hop option need to be 91 aware of this likely behaviour. 93 Fernando Gont, in his Observations on IPv6 EH Filtering in the Real 94 World [I-D.ietf-v6ops-ipv6-ehs-in-real-world], and the operational 95 community in IPv6 Operations, consider any punt to a software path to 96 be an attack vector. Hence, IPv6 packets containing the Hop-by-Hop 97 Extension Header (and in some cases, any extension header) get 98 dropped in transit. 100 The subject of this document is implementation approaches to obviate 101 or mitigate the attack vector, and updating the Hop-by-Hop option 102 with respect to current issues. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Handling of options in extension headers 112 In short, to avoid a punt to a software path, the Hop-by-Hop option 113 SHOULD be implemented in hardware when possible. 115 2.1. Hop-by_hop Options 117 At this writing, there are three defined Hop-by-Hop options: 119 PAD Options: The PAD1 and PADn options [RFC2460] define empty space. 121 Router Alert Option: The IPv6 Router Alert Option [RFC2711] 122 [RFC6398] is intended to force the punting of a datagram to 123 software, in cases in which RSVP or other protocols need that to 124 happen. 126 While this is not true of older hardware, modern hardware (which is 127 to say, microcode) is capable of parsing the Extension Header chain, 128 and can be extended to perform at least a cursory examination of the 129 Hop-by-Hop options. For example, such hardware should be able to 130 identify and skip the PAD1 and PADn options, and punt the Router 131 Alert or other options to software only if configured by software to 132 do so. 134 More generally, in routers that implement a fast path, the processing 135 of the Hop-by-Hop Extension Header (which must be performed by every 136 router a packet transits) MUST be performed in the fast path unless 137 there is a specific reason to punt to a slower path, including that 138 corresponding software exists in the implementation and is configured 139 to process the option. 141 2.2. Changing options in transit 143 Section 4.2 of [RFC2460] explicitly allows for options that may be 144 updated in transit. It is likely that the original authors intended 145 that to be very simple, such as having the originating end system 146 provide the container, and having intermediate systems update it - 147 perhaps performing some calculation, and in any event storing the 148 resulting value. Examples of such a use might be in [XCP] or [RCP]. 150 As a side comment, the Routing Header, which is an extension header 151 rather than a list of options, is treated similarly; when a system is 152 the destination of a packet and not the last one in the Routing 153 Header's list, it swaps the destination address with the indicated 154 address in the list, and updates the hop count and the list depth 155 accordingly. 157 Such options must be marked appropriately (their option type is of 158 the form XX1XXXXX), and are excluded from checksum calculations in AH 159 and ESP. 161 2.3. Adding headers or options in transit 163 Use cases under current consideration take this a step further: a 164 router or middleware process MAY add an extension header, MAY add an 165 option to the header, which may extend the length of the Hop-by-Hop 166 Extension Header, or MAY process such an option in a manner that 167 extends both the length of the option and the Extension Header 168 containing it. The obvious implication is that other equipment in 169 the network may not understand or implement the new option type. As 170 such, the Option Type value of such an option MUST indicate that it 171 is to be skipped by a system that does not understand it. Since, by 172 definition, it is being updated in transit and not included in any AH 173 or ESP integrity check if present, the Option Type MUST also indicate 174 that it may be updated in transit, and so is excluded from AH and ESP 175 processing. By implication, such an Option Type MUST be of the form 176 001XXXXX. 178 2.4. Interactions with the Security Extension Header 180 The interactions with the IP Authentication Header [RFC4302] and IP 181 Encapsulating Security Payload (ESP) [RFC4303], as in the case of 182 existing option uses, is minimally defined. AH and ESP call for the 183 exclusion of mutable data in their calculations by zeroing it out 184 prior to performing the integrity check calculation. However, in the 185 case that network operation has changed the length of the option or 186 the extension header, that may still cause the integrity check to 187 fail. Specifications that define such options SHOULD consider the 188 implications of this for AH and ESP. An option whose insertion would 189 affect the integrity check MUST be removed prior to the integrity 190 check, and as a result the packet restored to its state as originally 191 sent. 193 3. Interoperation with RFC 2460 195 There are four possible modes of interaction with routers that don't 196 implement the Hop-By-Hop Option in the fast path: 198 1. Presume that they cannot handle the Hop-By-Hop option at close to 199 wire speed, and that's OK. 201 2. Presume that they will drop traffic containing Hop-By-Hop 202 options. 204 3. Presume that they can handle the Hop-By-Hop option at or close to 205 wire speed, and are configured to do so. 207 4. Presume that they don't exist, perhaps because older routers are 208 configured to ignore all Hop-by-Hop options. 210 If the first model actually works in a given network, it may be 211 acceptable in that domain. It is not a model that will work in the 212 general Internet, however. 214 The second model (which is most probable at this writing) is a 215 description of the general Internet in 2015. 217 The third and fourth models, if applicable in a given context, are 218 what one might hope for. Vendors are in a position to either have an 219 option to ignore the Hop-By-Hop header in older equipment, or add 220 such an option in upgraded software. 222 4. IANA Considerations 224 This memo asks the IANA for no new parameters. 226 5. Security Considerations 228 In general, modification of a datagram in transit is considered very 229 closely from the viewpoint of the End-to-End Principle, which in this 230 context may be summarized as "the network should do nothing that is 231 of concern to the communicating applications or introduces 232 operational issues." The concept of changing the length of an 233 Extension Header or an option contained within it (Section 2.3) is of 234 concern in that context. The obvious concern is around the 235 interaction with AH or ESP, and a less obvious concern relates to 236 Path MTU, which might change if the size of an underlying header 237 changes. Section 2.4 is intended to mitigate that issue. However, 238 some ramifications, such as with Path MTU, may not be completely 239 solvable in the general Internet, but require use cases to be 240 confined to a network or set of consenting networks. 242 6. Privacy Considerations 244 Data formats in this memo reveal no personally identifying 245 information. 247 7. Acknowledgements 249 This note grew out of a discussion among the author, Ole Troan, Mark 250 Townsley, Frank Brockners, and Shwetha Bhandari, and benefited from 251 comments by Brian Carpenter and Joe Touch. 253 8. References 255 8.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 261 (IPv6) Specification", RFC 2460, December 1998. 263 8.2. Informative References 265 [I-D.ietf-v6ops-ipv6-ehs-in-real-world] 266 Gont, F., Linkova, J., Chown, T., and S. LIU, 267 "Observations on IPv6 EH Filtering in the Real World", 268 draft-ietf-v6ops-ipv6-ehs-in-real-world-00 (work in 269 progress), April 2015. 271 [RCP] Dukkipati, N., "Rate Control Protocol (RCP): Congestion 272 control to make flows complete quickly", Stanford 273 University , 2006. 275 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 276 RFC 2711, October 1999. 278 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 279 2005. 281 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 282 4303, December 2005. 284 [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and 285 Usage", BCP 168, RFC 6398, October 2011. 287 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 288 of IPv6 Extension Headers", RFC 7045, December 2013. 290 [XCP] Katabi, D., Handley, M., and C. Rohrs, "Congestion control 291 for high bandwidth-delay product networks", SIGCOMM 292 Symposium proceedings on Communications architectures and 293 protocols , 2002. 295 Appendix A. Change Log 297 Initial Version: June 2015 299 Author's Address 301 Fred Baker 302 Cisco Systems 303 Santa Barbara, California 93117 304 USA 306 Email: fred@cisco.com