idnits 2.17.1 draft-hinden-6man-hbh-processing-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 : ---------------------------------------------------------------------------- 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 (2 June 2021) is 1058 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 375, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-HBH' == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-ipv6-ehs-packet-drops-06 Summary: 1 error (**), 0 flaws (~~), 3 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: 4 December 2021 2 June 2021 8 IPv6 Hop-by-Hop Options Processing Procedures 9 draft-hinden-6man-hbh-processing-01 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 4 December 2021. 37 Copyright Notice 39 Copyright (c) 2021 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 Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Hop-by-Hop Header Processing Procedures . . . . . . . . . . . 5 58 5.1. Hop-by-Hop Options Per Packet . . . . . . . . . . . . . . 6 59 5.2. Hop-by-Hop Headers Processing . . . . . . . . . . . . . . 6 60 5.3. Router Alert Option . . . . . . . . . . . . . . . . . . . 7 61 5.4. Configuration . . . . . . . . . . . . . . . . . . . . . . 8 62 6. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 11 67 11. Normative References . . . . . . . . . . . . . . . . . . . . 11 68 12. Informative References . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 wire speed on the 146 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 200 [I-D.ietf-v6ops-ipv6-ehs-packet-drops]. 202 * Allowing multiple hop-by-hop options in a single packet makes it 203 even more expensive in router resources to process these packets. 204 It adds complexity to the number of permutations that might need 205 to be processed. 207 * Any mechanism that can be used to force packets into the router's 208 Slow Path can be exploited as a denial of service attack on a 209 transit router by saturating the resources needed for router 210 management protocols (e.g., routing protocols, network management 211 protocols, etc.) that may cause the router to fail. This issue 212 for the Router Alert option, which intentionally places packets on 213 the Slow Path, is discussed in [RFC6398]. Section 3 of that RFC 214 includes a good summary: 216 "In a nutshell, the IP Router Alert Option does not provide a 217 convenient universal mechanism to accurately and reliably 218 distinguish between IP Router Alert packets of interest and 219 unwanted IP Router Alert packets. This, in turn, creates a 220 security concern when the IP Router Alert Option is used, because, 221 short of appropriate router-implementation-specific mechanisms, 222 the router Slow Path is at risk of being flooded by unwanted 223 traffic." 225 There has been research that discussed the general problem with 226 dropping packets containing IPv6 extension headers, including the 227 Hop-by-Hop Options header. For example [Hendriks] states that 228 "dropping all packets with Extension Headers, is a bad practice", and 229 that "The share of traffic containing more than one EH however, is 230 very small. For the design of hardware able to handle the dynamic 231 nature of EHs, we therefore recommend to support at least one EH". 233 This document defines a set of procedures for the hop-by-hop option 234 header that make the processing of hop-by-hop options practical in 235 modern transit routers. 237 5. Hop-by-Hop Header Processing Procedures 239 This section describes several changes to [RFC8200]. 241 5.1. Hop-by-Hop Options Per Packet 243 The Hop-by-Hop Option Header as defined in Section 4.3 of [RFC8200] 244 is identified by a Next Header value of 0 in the IPv6 header. 245 Section 4.1 of [RFC8200] requires a Hop-by-Hop Options header to 246 appear immediately after the IPv6 header. [RFC8200] also requires 247 that a Hop-by-Hop Options header can only appear once in a packet. 249 The Hop-by-Hop Options Header as defined in [RFC8200] can contain one 250 or more Hop-by-Hop options. This document updates [RFC8200] that a 251 node MUST process the first Option in the Hop-by-Hop Header in the 252 Fast Path and MAY process additional Hop-by-Hop Options if configured 253 to do so. The motivation for this change is to simplify the 254 processing of Hop-by-Hop options in the Fast Path. 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 in the Fast Path, it MUST 276 behave as if it does not recognize the Option Type (as described in 277 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 to simplify what the router needs 316 to do in the Fast Path when it does not recognize the Option Type. 318 When an ICMP Parameter Problem, Code 2, message is delivered to the 319 source, the source can become aware that at least one node on the 320 patch has failed to recognize the option. 322 5.3. Router Alert Option 324 The Router Alert option [RFC2711] purpose is to tell the node that 325 the packet needs additional processing on the Slow Path. 327 The Router Alert option includes a two octet Value field that 328 describes the protocol that is carried in the packet. The current 329 values can be found in the IANA Router Alert Value registry 330 [IANA-RA]. 332 DISCUSSION 334 The Router Alert Option is a problem since it's function is to do 335 what this specification is proposing to eliminate, that is, 336 process the packet in the Slow Path. One approach would be to 337 deprecate it as it's usage appears to be limited and packets 338 containing Hop-by-Hop options are frequently dropped. Deprecation 339 would allow current implementations to continue and it's use could 340 be phased out over time. 342 The authors current thinking is that the Router Alert function may 343 have reasonable potential use for new functions that have to be 344 processed in the Slow Path. We think that keeping it as the 345 single exception for Slow Path processing with the following 346 restrictions is a reasonable compromise to allow future 347 flexibility. These are compatible with Section 5 of [RFC6398]. 349 A Fast Path implementation SHOULD verify that a Router Alert contains 350 a protocol, as indicated by the Value field in the Router Alert 351 option, that is configured as a protocol of interest to that router. 352 A verified packet SHOULD be sent on the Slow Path for processing 353 [RFC6398]. Otherwise, the router implementation SHOULD forward 354 within the Fast Path (subject to all normal policies and forwarding 355 rules). As specified in [RFC2711] the top two bits of Option Type 356 for the Router Alert option are always set to "00" indicating the 357 node should skip over this option and continue processing the header 358 in this case. 360 Implementations of the IP Router Alert Option SHOULD offer the 361 configuration option to simply ignore the presence of "IP Router 362 Alert" in IPv4 and IPv6 packets" [RFC6398]. 364 A node that is configured to process a Router Alert option using the 365 Slow Path MUST protect itself from infrastructure attack that could 366 result from processing on the Slow Path. This might include some 367 combination of access control list to only permit from trusted nodes, 368 rate limiting of processing, or other methods [RFC6398]. 370 5.4. Configuration 372 Section 4 of [RFC8200] allows for a router to control it's processing 373 of IPv6 Hop-by-Hop options by local configuration. The text is: 375 NOTE: While [RFC2460] required that all nodes must examine and 376 process the Hop-by-Hop Options header, it is now expected that 377 nodes along a packet's delivery path only examine and process the 378 Hop-by-Hop Options header if explicitly configured to do so. 380 A possible approach to implementing this is to maintain a lookup 381 table based on Option Type of the IPv6 options that are supported in 382 the Fast Path. This would allow for a node to quickly determine if 383 an option is supported and can be processed. If the option is not 384 supported, then the node processes it as described in Section 5.2 of 385 this document. 387 A node configured not to process HBH options, MUST drop the packet if 388 the top two bits of the Option Type field of the first HBH option is 389 non-zero. 391 The actions of the lookup table SHOULD be configurable by the 392 operator of the router. 394 6. New Hop-by-Hop Options 396 Any new IPv6 Hop-by-Hop option designed in the future should be 397 designed to be processed in the Fast Path. New options MUST NOT be 398 defined that require Slow Path processing. New Hop-by-Hop options 399 SHOULD have the following characteristics: 401 * Straight forward to process. That is, they should be designed to 402 keep the time to process low. 404 * Fixed size in 8-octet units. Specifically any new Hop-by-Hop 405 options should not be variable size that could extend beyond what 406 can be executed in the Fast Path. 408 Any new Hop-by-Hop option that is standardized that does not meet 409 these criteria needs to explain in detail in its specification why 410 this can not be accomplished and that there is a reasonable 411 expectation that it can be proceed in most Fast Path implementations. 413 7. IANA Considerations 415 There are no actions required for IANA defined in this document. 417 8. Security Considerations 419 Security issues with IPv6 Hop-by-Hop options are well known and have 420 been documented in several places, including [RFC6398], [RFC6192], 421 and [I-D.ietf-v6ops-ipv6-ehs-packet-drops]. The main issue, as noted 422 in Section 4, is that any mechanism that can be used to force packets 423 into the router's Slow Path can be exploited as a denial of service 424 attack on a transit router by saturating the resources need for 425 router management protocols (e.g., routing protocols, network 426 management protocols, etc.) that may cause the router to fail. Due 427 to this it's common for transit routers to drop packets with Hop-by- 428 Hop options headers. 430 While Hop-by-Hop options are not required to be processed in the Slow 431 Path, the Router Alert options is designed to do just that. 433 This document changes the way Hop-by-Hop options are processed in 434 several ways that significantly reduces the attack surface. These 435 changes include: 437 * All Hop-by-Hop options (with one exception) must be processed in 438 the Fast Path. Only one HBH Option MUST be processed and 439 additional HBH Options MAY be processed based on local 440 configuration. 442 * Only the Router Alert option can be processed in the Slow Path, 443 and the router must be configured to do so. 445 * Added criteria to allow control over how Router Alert options are 446 processed and that a node configured to support these options must 447 protect itself from attacks using the Router Alert. 449 * Limited the default number of Hop-by-Hop options that that can be 450 in a packet to a single Hop-by-Hop option. 452 * Additional Hop-by-Hop options MAY be included, based on local 453 configuration. Although nodes only process these additional Hop- 454 by-Hop Options if configured to do so. 456 * Added restrictions to any future new Hop-by-Hop options that limit 457 their size and computational requirements. 459 The authors believe that these changes significantly reduces the 460 security issues relating to IPv6 Hop-by-Hop options and will enable 461 them to be used safely in the Internet. 463 9. Acknowledgments 465 Helpful comments were received from Brian Carpenter, Ron Bonica, Ole 466 Troan, Mark Heard, Tom Herbert, [your name here], and other members 467 of the 6MAN working group. 469 10. Change log [RFC Editor: Please remove] 471 draft-hinden-6man-hbh-processing-01, 2021-June-2: 473 * Expanded terminology section to include Forwarding Plane and 474 Control Plane. 475 * Changed draft that only one HBH Option MUST be processed and 476 additional HBH Options MAY be processed based on local 477 configuration. 478 * Clarified that all HBH options (with one exception) must be 479 processed on the Fast Path. 480 * Kept the Router Alert options as the single exception for Slow 481 Path processing. 482 * Rewrote and expanded section on New Hop-by-Hop Options. 483 * Removed requirement for HBH Option size and alignment. 484 * Removed sections evaluating currently defined HBH Options. 485 * Added content to the Security Considerations section. 486 * Added people to the acknowledgements section. 487 * Numerous editorial changes 489 draft-hinden-6man-hbh-processing-00, 2020-Nov-29: 491 * Initial draft. 493 11. Normative References 495 [IANA-HBH] "Destination Options and Hop-by-Hop Options", 496 . 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, 501 DOI 10.17487/RFC2119, March 1997, 502 . 504 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 505 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 506 May 2017, . 508 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 509 (IPv6) Specification", STD 86, RFC 8200, 510 DOI 10.17487/RFC8200, July 2017, 511 . 513 12. Informative References 515 [Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. 516 Aiko, "Threats and Surprises behind IPv6 Extension 517 Headers", August 2017, 518 . 521 [I-D.ietf-v6ops-ipv6-ehs-packet-drops] 522 Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 523 G., and W. (. Liu, "Operational Implications of IPv6 524 Packets with Extension Headers", Work in Progress, 525 Internet-Draft, draft-ietf-v6ops-ipv6-ehs-packet-drops-06, 526 8 April 2021, . 529 [IANA-RA] "IPv6 Router Alert Option Values", 530 . 533 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 534 RFC 2711, DOI 10.17487/RFC2711, October 1999, 535 . 537 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 538 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 539 March 2011, . 541 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 542 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 543 2011, . 545 Authors' Addresses 547 Robert M. Hinden 548 Check Point Software 549 959 Skyway Road 550 San Carlos, CA 94070 551 United States of America 553 Email: bob.hinden@gmail.com 555 Godred Fairhurst 556 University of Aberdeen 557 School of Engineering, Fraser Noble Building 558 Aberdeen 559 AB24 3UE 560 United Kingdom 562 Email: gorry@erg.abdn.ac.uk