idnits 2.17.1 draft-ietf-6man-hbh-processing-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 January 2022) is 790 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) == Missing Reference: 'RFC2460' is mentioned on line 376, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-HBH' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hinden 3 Internet-Draft Check Point Software 4 Updates: 8200 (if approved) G. Fairhurst 5 Intended status: Standards Track University of Aberdeen 6 Expires: 2 August 2022 29 January 2022 8 IPv6 Hop-by-Hop Options Processing Procedures 9 draft-ietf-6man-hbh-processing-00 11 Abstract 13 This document specifies procedures for how IPv6 Hop-by-Hop options 14 are processed. It modifies the procedures specified in the IPv6 15 Protocol Specification (RFC8200) to make processing of IPv6 Hop-by- 16 Hop options practical with the goal of making IPv6 Hop-by-Hop options 17 useful to deploy and use in the Internet. When published, this 18 document updates RFC8200. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 2 August 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Hop-by-Hop Header Processing Procedures . . . . . . . . . . . 6 58 5.1. Hop-by-Hop Options Per Packet . . . . . . . . . . . . . . 6 59 5.2. Hop-by-Hop Headers Processing . . . . . . . . . . . . . . 7 60 5.3. Router Alert Option . . . . . . . . . . . . . . . . . . . 8 61 5.4. Configuration . . . . . . . . . . . . . . . . . . . . . . 9 62 6. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 11 67 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 68 12. Informative References . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 This document specifies procedures for how IPv6 Hop-by-Hop options 74 are processed. It modifies the procedures specified in the IPv6 75 Protocol Specification (RFC8200) to make processing of IPv6 Hop-by- 76 Hop options practical with the goal of making IPv6 Hop-by-Hop options 77 useful to deploy and use in the Internet. 79 When published this document updates [RFC8200]. 81 The current list of defined Hop-by-Hop options can be found at 82 [IANA-HBH]. 84 2. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in BCP 89 14 [RFC2119] [RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 3. Terminology 94 This document uses the following loosely defined terms: 96 * Forwarding Plane: IPv6 hosts exchange user data through the 97 forwarding plane. User data is processed by its recipient (i.e., 98 an IPv6 host). User data can traverse intermediate nodes (i.e., 99 routers) between its source and its destination. These 100 intermediate nodes process metadata contained in packet headers. 101 However, they do not process information contained in packet 102 payloads. 104 * Control Plane: IPv6 routers exchange management and routing 105 information with controllers. They also exchange routing 106 information with one another. Management and routing information 107 is processed by its recipient (i.e., an IPv6 router or 108 controller). Management and control information can traverse 109 intermediate nodes (i.e., routers) between its source and its 110 destination. These intermediate nodes process metadata contained 111 in packet headers. However, they do not process information 112 contained in packet payloads. So, from their perspective, this 113 information is user data. 115 * Fast Path: A path through a router that is optimized for 116 forwarding packets without processing their payloads. The Fast 117 Path may be supported by Application Specific Integrated Circuits 118 (ASICS), Network Processor (NP), or other special purpose 119 hardware. This is the usual processing path within a router taken 120 by the forwarding plane. 122 * Slow Path: A path through a router that is capable of general 123 purpose processing and is not optimized for any particular 124 function. This is processing path is used for packets that 125 require special processing or differ from assumptions made in Fast 126 Path heuristics, or to process router control protocols used by 127 the control plane. 129 NOTE: This distinct separation between hardware and software 130 processing from [RFC6398] does not apply to all router architectures. 131 However, a router that performs all or most processing in software 132 might still incur more processing cost when providing special 133 processing (aka Slow Path). 135 [RFC6192] is an example of how designs can separate control plane 136 (Slow Path) and forwarding plane (Fast Path) functions. 138 4. Background 140 In the first version of the IPv6 specification, Hop-by-Hop options 141 were required to be processed by all nodes: routers and hosts. This 142 proved to not be practical in high speed routers due to several 143 factors, including: 145 * Inability to process the hop-by-hop options at full the forwarding 146 rate (e.g., routers with no support on the Fast Path). 148 * Hop-by-Hop options would be sent to the Slow Path. This could 149 could degrade the a router's performance and it's ability to 150 process important control traffic. 152 * A mechanism that forces packets from any source to the routers 153 "Slow Path" could be exploited as a Denial of Service attack 154 against the router. 156 * Packets could contain multiple Hop-by-Hop options making the 157 previous issues worse by increasing the complexity required to 158 process them. 160 When the IPv6 Specification was updated and published in July 2017 as 161 [RFC8200], the procedures relating to hop-by-hop options were as 162 follows: 164 Extension headers (except for the Hop-by-Hop Options header) are 165 not processed, inserted, or deleted by any node along a packet's 166 delivery path, until the packet reaches the node (or each of the 167 set of nodes, in the case of multicast) identified in the 168 Destination Address field of the IPv6 header. 170 The Hop-by-Hop Options header is not inserted or deleted, but may 171 be examined or processed by any node along a packet's delivery 172 path, until the packet reaches the node (or each of the set of 173 nodes, in the case of multicast) identified in the Destination 174 Address field of the IPv6 header. The Hop-by-Hop Options header, 175 when present, must immediately follow the IPv6 header. Its 176 presence is indicated by the value zero in the Next Header field 177 of the IPv6 header. 179 NOTE: While [RFC2460] required that all nodes must examine and 180 process the Hop-by-Hop Options header, it is now expected that 181 nodes along a packet's delivery path only examine and process the 182 Hop-by-Hop Options header if explicitly configured to do so. 184 The changes meant that an implementation complied with the IPv6 185 specification even if it did not process hop-by-hop options, and that 186 it was expected that routers would add configuration information to 187 control which hop-by-hop options they would process. 189 Unfortunately, this did not improve the processing of Hop-by-Hop 190 options and did not significantly improve deployment and use in the 191 Internet. Essentially, it only documented how they were being used 192 in the Internet at the time RFC8200 was published. 194 The main issues remain: 196 * Routers are commonly configured to drop transit packets containing 197 hop-by-hop options that would have be processed in the Slow Path. 198 This behavior is seen as protecting against a denial of service 199 attack on the router. This is discussed in [RFC9098]. 201 * Allowing multiple hop-by-hop options in a single packet makes it 202 even more expensive in router resources to process these packets. 203 It adds complexity to the number of permutations that might need 204 to be processed. 206 * Any mechanism that can be used to force packets into the router's 207 Slow Path can be exploited as a denial of service attack on a 208 transit router by saturating the resources needed for router 209 management protocols (e.g., routing protocols, network management 210 protocols, etc.) that may cause the router to fail. This issue 211 for the Router Alert option, which intentionally places packets on 212 the Slow Path, is discussed in [RFC6398]. Section 3 of that RFC 213 includes a good summary: 215 "In a nutshell, the IP Router Alert Option does not provide a 216 convenient universal mechanism to accurately and reliably 217 distinguish between IP Router Alert packets of interest and 218 unwanted IP Router Alert packets. This, in turn, creates a 219 security concern when the IP Router Alert Option is used, because, 220 short of appropriate router-implementation-specific mechanisms, 221 the router Slow Path is at risk of being flooded by unwanted 222 traffic." 224 There has been research that discussed the general problem with 225 dropping packets containing IPv6 extension headers, including the 226 Hop-by-Hop Options header. For example [Hendriks] states that 227 "dropping all packets with Extension Headers, is a bad practice", and 228 that "The share of traffic containing more than one EH however, is 229 very small. For the design of hardware able to handle the dynamic 230 nature of EHs, we therefore recommend to support at least one EH". 232 This document defines a set of procedures for the hop-by-hop option 233 header that make the processing of hop-by-hop options practical in 234 modern transit routers. 236 5. Hop-by-Hop Header Processing Procedures 238 This section describes several changes to [RFC8200]. 240 5.1. Hop-by-Hop Options Per Packet 242 The Hop-by-Hop Option Header as defined in Section 4.3 of [RFC8200] 243 is identified by a Next Header value of 0 in the IPv6 header. 244 Section 4.1 of [RFC8200] requires a Hop-by-Hop Options header to 245 appear immediately after the IPv6 header. [RFC8200] also requires 246 that a Hop-by-Hop Options header can only appear once in a packet. 248 The Hop-by-Hop Options Header as defined in [RFC8200] can contain one 249 or more Hop-by-Hop options. This document updates [RFC8200] that a 250 node MUST process the first Option in the Hop-by-Hop Header at full 251 forwarding rate the (e.g. on the router's Fast Path) and MAY process 252 additional Hop-by-Hop Options if configured to do so. The motivation 253 for this change is to simplify the processing of Hop-by-Hop options 254 as a part of normal forwarding. 256 Nodes creating packets with a Hop-by-Hop option headers SHOULD 257 include a single Hop-by-Hop Option in the packet and MAY include more 258 based on local configuration. 260 If there are more than one Hop-by-Hop options in the Hop-by-Hop 261 Options header, the node MAY skip the rest of the options without 262 having to examine these options using the "Hdr Ext Len" field in the 263 Hop-by-Hop Options header. This field specifies the length of the 264 Option Header in 8-octet units. The additional options do not need 265 to be processed or verified. 267 5.2. Hop-by-Hop Headers Processing 269 Nodes that implement a differentiation between a Fast Path and a Slow 270 Path MUST process all (with one exception noted below) Hop-by-Hop 271 options in the Fast Path. The one exception to this is the Router 272 Alert Option [RFC2711]. See Section 5.3 for discussion of the Router 273 Alert. 275 If the node can not process an option at the full forwarding rate, it 276 MUST behave as if it does not recognize the Option Type (as described 277 in the next paragraph). 279 Section 4.2 of [RFC8200] defines the Option Type identifiers as 280 internally encoded such that their highest-order 2 bits specify the 281 action that must be taken if the processing IPv6 node does not 282 recognize the Option Type. The text is: 284 00 - skip over this option and continue processing the header. 286 01 - discard the packet. 288 10 - discard the packet and, regardless of whether or not the 289 packet's Destination Address was a multicast address, send an 290 ICMP Parameter Problem, Code 2, message to the packet's 291 Source Address, pointing to the unrecognized Option Type. 293 11 - discard the packet and, only if the packet's Destination 294 Address was not a multicast address, send an ICMP Parameter 295 Problem, Code 2, message to the packet's Source Address, 296 pointing to the unrecognized Option Type. 298 This document modifies this behaviour for the "10" and "11" values 299 that the node MAY send an ICMP Parameter Problem, Code 2, message to 300 the packet's Source Address, pointing to the unrecognized Option 301 Type. The modified text for "10" and 11" values is: 303 10 - discard the packet and, regardless of whether or not the 304 packet's Destination Address was a multicast address, MAY 305 send an ICMP Parameter Problem, Code 2, message to the 306 packet's Source Address, pointing to the unrecognized Option 307 Type. 309 11 - discard the packet and, only if the packet's Destination 310 Address was not a multicast address, MAY send an ICMP 311 Parameter Problem, Code 2, message to the packet's Source 312 Address, pointing to the unrecognized Option Type. 314 The motivation for this change is to loosen the requirement to send 315 ICMPv6 Parameter Problem messages by simplifying what the router 316 needs to do when it performs forwarding of an Option Type it does not 317 recognize. 319 When an ICMP Parameter Problem, Code 2, message is delivered to the 320 source, the source can become aware that at least one node on the 321 patch has failed to recognize the option. 323 5.3. Router Alert Option 325 The Router Alert option [RFC2711] purpose is to tell the node that 326 the packet needs additional processing on the Slow Path. 328 The Router Alert option includes a two octet Value field that 329 describes the protocol that is carried in the packet. The current 330 values can be found in the IANA Router Alert Value registry 331 [IANA-RA]. 333 DISCUSSION 335 The Router Alert Option is a problem since it's function is to do 336 what this specification is proposing to eliminate, that is, 337 process the packet in the Slow Path. One approach would be to 338 deprecate it as it's usage appears to be limited and packets 339 containing Hop-by-Hop options are frequently dropped. Deprecation 340 would allow current implementations to continue and it's use could 341 be phased out over time. 343 The authors current thinking is that the Router Alert function may 344 have reasonable potential use for new functions that have to be 345 processed in the Slow Path. We think that keeping it as the 346 single exception for Slow Path processing with the following 347 restrictions is a reasonable compromise to allow future 348 flexibility. These are compatible with Section 5 of [RFC6398]. 350 A Fast Path implementation SHOULD verify that a Router Alert contains 351 a protocol, as indicated by the Value field in the Router Alert 352 option, that is configured as a protocol of interest to that router. 353 A verified packet SHOULD be sent on the Slow Path for processing 354 [RFC6398]. Otherwise, the router implementation SHOULD forward 355 within the Fast Path (subject to all normal policies and forwarding 356 rules). As specified in [RFC2711] the top two bits of Option Type 357 for the Router Alert option are always set to "00" indicating the 358 node should skip over this option and continue processing the header 359 in this case. 361 Implementations of the IP Router Alert Option SHOULD offer the 362 configuration option to simply ignore the presence of "IP Router 363 Alert" in IPv4 and IPv6 packets" [RFC6398]. 365 A node that is configured to process a Router Alert option using the 366 Slow Path MUST protect itself from infrastructure attack that could 367 result from processing on the Slow Path. This might include some 368 combination of access control list to only permit from trusted nodes, 369 rate limiting of processing, or other methods [RFC6398]. 371 5.4. Configuration 373 Section 4 of [RFC8200] allows for a router to control it's processing 374 of IPv6 Hop-by-Hop options by local configuration. The text is: 376 NOTE: While [RFC2460] required that all nodes must examine and 377 process the Hop-by-Hop Options header, it is now expected that 378 nodes along a packet's delivery path only examine and process the 379 Hop-by-Hop Options header if explicitly configured to do so. 381 A possible approach to implementing this is to maintain a lookup 382 table based on Option Type of the IPv6 options that are supported in 383 the Fast Path. This would allow for a node to quickly determine if 384 an option is supported and can be processed. If the option is not 385 supported, then the node processes it as described in Section 5.2 of 386 this document. 388 A node configured not to process HBH options, MUST drop the packet if 389 the top two bits of the Option Type field of the first HBH option is 390 non-zero. 392 The actions of the lookup table SHOULD be configurable by the 393 operator of the router. 395 6. New Hop-by-Hop Options 397 Any new IPv6 Hop-by-Hop option designed in the future should be 398 designed to be processed at full forwarding rate (e.g., on a router's 399 Fast Path). New options MUST NOT be defined that are not reasonably 400 expected to be executed at full forwarding rates. New Hop-by-Hop 401 options SHOULD have the following characteristics: 403 * Straight forward to process. That is, they should be designed to 404 keep the time to process low. 406 * New Hop-by-Hop options should be designed to be the first option 407 in a Hop-by-Hop options header. 409 * The size of an option should not extend beyond what can be 410 reasonably expected to be executed at full forwarding rate (e.g., 411 forwarded on a router's fast path). 413 Any new Hop-by-Hop option that is standardized that does not meet 414 these criteria needs to explain in detail in its specification why 415 this can not be accomplished and that there is a reasonable 416 expectation that it can be proceed in most Fast Path implementations. 418 7. IANA Considerations 420 There are no actions required for IANA defined in this document. 422 8. Security Considerations 424 Security issues with IPv6 Hop-by-Hop options are well known and have 425 been documented in several places, including [RFC6398], [RFC6192], 426 and [RFC9098]. The main issue, as noted in Section 4, is that any 427 mechanism that can be used to force packets into the router's Slow 428 Path can be exploited as a denial of service attack on a transit 429 router by saturating the resources need for router management 430 protocols (e.g., routing protocols, network management protocols, 431 etc.) that may cause the router to fail. Due to this it's common for 432 transit routers to drop packets with Hop-by-Hop options headers. 434 While Hop-by-Hop options are not required to be processed in the Slow 435 Path, the Router Alert options is designed to do just that. 437 This document changes the way Hop-by-Hop options are processed in 438 several ways that significantly reduces the attack surface. These 439 changes include: 441 * All Hop-by-Hop options (with one exception) must be processed in 442 the Fast Path. Only one HBH Option MUST be processed and 443 additional HBH Options MAY be processed based on local 444 configuration. 446 * Only the Router Alert option can be processed in the Slow Path, 447 and the router must be configured to do so. 449 * Added criteria to allow control over how Router Alert options are 450 processed and that a node configured to support these options must 451 protect itself from attacks using the Router Alert. 453 * Limited the default number of Hop-by-Hop options that that can be 454 in a packet to a single Hop-by-Hop option. 456 * Additional Hop-by-Hop options MAY be included, based on local 457 configuration. Although nodes only process these additional Hop- 458 by-Hop Options if configured to do so. 460 * Added restrictions to any future new Hop-by-Hop options that limit 461 their size and computational requirements. 463 The authors believe that these changes significantly reduces the 464 security issues relating to IPv6 Hop-by-Hop options and will enable 465 them to be used safely in the Internet. 467 9. Acknowledgments 469 Helpful comments were received from Brian Carpenter, Ron Bonica, Ole 470 Troan, Mark Heard, Tom Herbert, [your name here], and other members 471 of the 6MAN working group. 473 10. Change log [RFC Editor: Please remove] 475 draft-ietf-6man-hbh-processing-00, 2022-January-29: 477 * 6MAN Working Group Draft 478 * Reworked text to talk about processing HBH options at full 479 forwarding rates, instead of "fast path" 480 * Revised Section 6 "New Hop-by-Hop Options" to allow variable sized 481 HBH options, remove specific length requirements, and other 482 clarifications. 483 * Editorial changes. 485 draft-hinden-6man-hbh-processing-01, 2021-June-2: 487 * Expanded terminology section to include Forwarding Plane and 488 Control Plane. 489 * Changed draft that only one HBH Option MUST be processed and 490 additional HBH Options MAY be processed based on local 491 configuration. 492 * Clarified that all HBH options (with one exception) must be 493 processed on the Fast Path. 494 * Kept the Router Alert options as the single exception for Slow 495 Path processing. 496 * Rewrote and expanded section on New Hop-by-Hop Options. 497 * Removed requirement for HBH Option size and alignment. 498 * Removed sections evaluating currently defined HBH Options. 499 * Added content to the Security Considerations section. 500 * Added people to the acknowledgements section. 501 * Numerous editorial changes 503 draft-hinden-6man-hbh-processing-00, 2020-Nov-29: 505 * Initial draft. 507 11. Normative References 509 [IANA-HBH] "Destination Options and Hop-by-Hop Options", 510 . 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 519 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 520 May 2017, . 522 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 523 (IPv6) Specification", STD 86, RFC 8200, 524 DOI 10.17487/RFC8200, July 2017, 525 . 527 12. Informative References 529 [Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. 530 Aiko, "Threats and Surprises behind IPv6 Extension 531 Headers", , August 2017, 532 . 535 [IANA-RA] "IPv6 Router Alert Option Values", 536 . 539 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 540 RFC 2711, DOI 10.17487/RFC2711, October 1999, 541 . 543 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 544 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 545 March 2011, . 547 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 548 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 549 2011, . 551 [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 552 G., and W. Liu, "Operational Implications of IPv6 Packets 553 with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, 554 September 2021, . 556 Authors' Addresses 558 Robert M. Hinden 559 Check Point Software 560 959 Skyway Road 561 San Carlos, CA 94070 562 United States of America 564 Email: bob.hinden@gmail.com 566 Godred Fairhurst 567 University of Aberdeen 568 School of Engineering 569 Fraser Noble Building 570 Aberdeen 571 AB24 3UE 572 United Kingdom 574 Email: gorry@erg.abdn.ac.uk