idnits 2.17.1 draft-herbert-6man-eh-attrib-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 == Line 581 has weird spacing: '...llowing attri...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - If the error was caused by inserted extension headers, then the node SHOULD take appropriate actions (minimally it SHOULD log the error). The filtering node SHOULD not forward the ICMP error to the source. -- The document date (July 7, 2020) is 1387 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-01 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Herbert 3 Internet-Draft Intel 4 Intended status: Experimental July 7, 2020 5 Expires: January 8, 2021 7 Attribution Option for Extension Header Insertion 8 draft-herbert-6man-eh-attrib-01 10 Abstract 12 This document defines an "attribution option" that provides 13 attribution for IPv6 extension headers, Hop-by-Hop options, or 14 Destination options that are inserted by intermediate nodes in the 15 delivery path of a packet. The purpose of this option is twofold: 16 first it identifies the extension headers or options that have been 17 inserted, secondly it attributes the inserted extension headers or 18 options to the node responsible for inserting them. 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 January 8, 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Motivation for extension header insertion . . . . . . . . 3 56 1.2. Problems with extension header and options insertion . . 4 57 1.3. Inserting Hop-by-Hop options . . . . . . . . . . . . . . 5 58 1.4. Inserting Destination options . . . . . . . . . . . . . . 5 59 1.5. Inserting extension headers . . . . . . . . . . . . . . . 5 60 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.7. Requirements Language . . . . . . . . . . . . . . . . . . 6 62 2. Attribution Option . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1.1. Attribution Option with short identifier . . . . . . 7 65 2.1.2. Attribution Option with IPv6 address identifier . . . 8 66 2.2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1. Insertion . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.1.1. Insertion procedure . . . . . . . . . . . . . . . . . 10 70 3.1.2. Errors during insertion . . . . . . . . . . . . . . . 11 71 3.2. Removal of inserted extension headers and options . . . . 12 72 3.2.1. Removal procedure . . . . . . . . . . . . . . . . . . 12 73 3.2.2. Errors during removal . . . . . . . . . . . . . . . . 13 74 3.3. Domain edge filtering . . . . . . . . . . . . . . . . . . 13 75 3.4. ICMP processing . . . . . . . . . . . . . . . . . . . . . 14 76 3.5. Processing AH . . . . . . . . . . . . . . . . . . . . . . 15 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 6.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 Extension header insertion has been proposed as a mechanism to 87 annotate packets for transit across controlled, or limited, domains 88 ([I-D.voyer-6man-extension-header-insertion], 89 [I-D.ietf-ippm-ioam-ipv6-options]). These annotations are in the 90 form of inserted Hop-by-Hop or Destination options, or other inserted 91 extension headers (Segment Routing Header for example). Presumably, 92 before a packet egresses a controlled domain, any inserted extension 93 headers or options should be removed. 95 Extension header insertion, removal, and other non-standard 96 modifications at intermediate nodes are currently prohibited by 98 [RFC8200], and [I-D.smith-6man-in-flight-eh-insertion-harmful] 99 provides the rationale for why extension header insertion is harmful 100 and thus prohibited. 102 This document addresses the main problem of extension header 103 insertion which is the loss of attribution to the source of packet 104 contents. An "attribution option", either as a Hop-by-Hop or 105 Destination Option, is defined to provide proper attribution. There 106 are two salient aspects to this: 108 * The attribution option unambiguously identifies what extension 109 headers and Destination or Hop-by-Hop options were inserted by 110 intermediate nodes. 112 * The attribution option includes an identification of the 113 intermediate node that inserted extension headers or options 114 into a packet. 116 1.1. Motivation for extension header insertion 118 IP-in-IP encapsulation has been proposed as an alternative to 119 extension header insertion. While encapsulation may be functionally 120 equivalent to header insertion, there are merits to header insertion: 122 * Extension header insertion can result in fewer bytes of 123 overhead than encapsulation. 125 * The proper destination address to set in the encapsulating IP 126 header may be unknown. For instance, a node might insert an 127 extension header into an existing packet with the intent that 128 the packet is routed based on the original destination to some 129 egress node of the domain that will remove the inserted 130 headers. 132 * Packets for a flow may require consistent routing whether or 133 not extension headers are inserted. In particular, to route 134 flows consistently in Equal Cost MultiPath (ECMP), the hash 135 computed for ECMP should be the same for all packets of the 136 flow. Unlike IP encapsulation, extension header insertion 137 doesn't affect the fields used in ECMP hash calculation (the 138 source address, destination address, flow label, and transport 139 layer ports), so the ECMP hash calculation consistently derives 140 the same value for all packets of a flow with or without 141 inserted extension headers or options. 143 1.2. Problems with extension header and options insertion 145 Insertion or removal of extension headers, as well as Destination or 146 Hop-by-Hop options, is currently prohibited by [RFC8200]: 148 Extension headers (except for the Hop-by-Hop Options header) 149 are not processed, inserted, or deleted by any node along a 150 packet's delivery path, until the packet reaches the node (or 151 each of the set of nodes, in the case of multicast) identified 152 in the Destination Address field of the IPv6 header. 154 The rationale for this prohibition is articulated in [I-D.smith-6man- 155 in-flight-eh-insertion-harmful]. A summary of cited problems with 156 extension header and options insertion are: 158 * It breaks the attribution model of IP in that the contents of a 159 packet are no longer attributable to the node identified by the 160 source address of a packet (exceptions include data that a 161 source sets in a packet that is explicitly specified to be 162 modifiable). 164 * It breaks PMTU discovery since extension header insertion 165 increases the packet size in flight. 167 * It breaks ICMP since inserted extension headers may themselves 168 cause ICMP errors that are sent to the source address. If the 169 source node receives such an ICMP error it cannot take any 170 action to resolve the error since it's not the source of the 171 data that caused the error. 173 * Extension header or options insertion may create a 174 communications black hole if the data inserted by one node 175 causes the packet to be dropped at a later downstream node. 176 When this happens the source does not know the node that 177 inserted the data and won't even know the node dropping the 178 packet unless a ICMP error is sent. In any case, the sending 179 host cannot address the issue hence persistent systematic 180 packet loss is possible. Such a scenario may be difficult to 181 trouble shoot in an even moderately large network. 183 * Use of extension header insertion is generally assumed to be 184 confined to a controlled domain where the domain is a walled 185 garden such that inserted extension headers are always removed 186 before packets would exit a domain. It is conceivable that 187 configuration or implementation errors may allow packets with 188 inserted extension headers to leak out of the controlled 189 domain. 191 * It breaks the IP Authentication Header (AH) [RFC4302]. If a 192 receiving node attempts to verify an authentication header that 193 covers data inserted by intermediate nodes, then the packet 194 authentication will fail and the packet will be dropped. 196 This proposal primarily addresses the attribution of packet contents 197 problem. A solution to the attribution problem addresses or at least 198 can mitigate the other problems with extension header insertion. 200 1.3. Inserting Hop-by-Hop options 202 For inserting Hop-by-Hop options into a packet there are two 203 possibilities: 1) a Hop-by-Hop Options extension header already 204 exists in the packet, 2) no Hop-by-Hop Options extension header exist 205 in the packet so a Hop-by-Hop extension header is inserted into the 206 packet which contains the options being inserted. 208 Note that per [RFC8200] there can only be one Hop-by-Hop Options 209 extension header in a packet, and if present it must be the first 210 extension header after the IPv6 header. If Hop-by-Hop Options are to 211 be inserted into a packet with an existing Hop-by-Hop Options 212 extension header, the the options MUST be inserted into the options 213 list for the existing extension header. 215 1.4. Inserting Destination options 217 Destination options may be inserted in Destination Options before or 218 after the routing header. If an appropriate Destination Options 219 extension header does not exist in the packet then a new Destination 220 Options extension header containing the inserted options is inserted 221 in the packet. The recommended ordering of extension headers in 222 [RFC8200] SHOULD be maintained. 224 1.5. Inserting extension headers 226 When an extension header, not Hop-by-Hop or Destination, is inserted 227 into a packet it is immediately preceded by a Destination Options 228 extension header that includes an attribution option which describes 229 the inserted extension header. If the extension header is being 230 inserted immediately after an existing Destination Options extension 231 header then the attribution option is inserted into the existing 232 Destination Options extension header. If there is no preceding 233 Destination Options extension header then a header is created into 234 which the attribution options is set. 236 1.6. Scope 238 This document describes a mechanism for providing attribution in 239 extension header insertion and insertion of Hop-by-Hop and 240 Destination Options. With the exception of inserting Hop-by-Hop 241 Options and Destination Options, requirements and semantics for 242 inserting specific types of extension headers are out of scope. 243 Similarly, security aspects, including potential leakage of inserted 244 headers outside of a controlled domain, is not in scope. 246 1.7. Requirements Language 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in [RFC2119]. 252 2. Attribution Option 254 2.1. Format 256 The format of the Hop-by-Hop or Destination Attribution Option is: 258 0 1 2 3 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Option Type | Opt Data Len | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |E| Num_opts | | 264 +-+-+-+-+-+-+-+-+ + 265 | | 266 ~ Identification ~ 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Fields are: 272 * Option Type: value is TBA. The first three bits of the option 273 type should be 000 to indicate that the option is to be skipped 274 over when processed as an unknown option and that the option 275 data is unmodifiable. 277 * Opt Data Len: data length for the option. The minimal data 278 length is one. If the data length equals twenty then the 279 Identification is an IPv6 address (see section 2.1.2). 281 * E: For Destination Options this indicates that the extension 282 header following the Destination Options extension header has 283 been inserted. When the option is in Hop-by-Hop Options, this 284 bit MUST be zero when when transmitting and ignored on receive. 286 * Num_opts: If this value is less than 127 then it indicates the 287 number of non-padding options following the Attribution Option 288 that are attributed as being inserted. If the value is 127 289 then this indicates that the extension header was inserted and 290 all following options are attributed as being inserted. Note 291 that the maximum number of inserted options attributed but one 292 Attribution Option is 126. 294 * Identification: indicates the source node responsible for the 295 inserted extension headers. This can either be the IPv6 296 address of the responsible node or a local identifier value 297 that is interpreted by the local network domain (see examples 298 below). Note this field is variable length. 300 If options are being inserted into an existing Destination Options or 301 Hop-by-Hop extension header then the Attribution Option is inserted 302 as the first option in the header, followed by any inserted options, 303 and then followed by any pre-existing options. The total length of 304 the attribution option and and any inserted options MUST be 8n; this 305 ensures that any pre-existing options following those being inserted 306 retain their original alignment. After the last inserted option the 307 minimum amount of padding is added to make the total length of 308 inserted data 8n. Pre-existing options, including padding, MUST NOT 309 be modified other than moving them to follow the inserted options. 311 If a Destination or Hop-by-Hop Options extension header is being 312 inserted in a packet then the Attribution Option is set as the first 313 option in the header followed by an inserted options. Minimal 314 padding MUST added make the length of the extension header 8n. 316 2.1.1. Attribution Option with short identifier 318 Below is the short format of the Attribution Option. 320 0 1 2 3 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | 4 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |E| Num opts | Local_ID | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Local_ID is interpreted locally. For instance, it may be used as an 329 index to a table to map a value to an IPv6 address. 331 2.1.2. Attribution Option with IPv6 address identifier 333 Below is the format of the Attribution Option that contains an IPv6 334 address for attribution of the inserted extension headers or options. 336 0 1 2 3 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | 20 | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |E| Num opts | Local_ID | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 + + 345 | | 346 + IPv6 address + 347 | | 348 + + 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Local_ID contains supplemental identification that is interpreted by 353 the local network. This MAY be the AS of network corresponding to 354 the node identified by the IPv6 address. 356 2.2. Model 358 The Attribution Option indicates both inserted Hop-by-Hop or 359 Destination options and inserted extension headers. 361 Multiple extension header or options insertions may occur during the 362 lifetime of a packet. Insertions are treated as a stack. Hop-by-Hop 363 and Destination options MUST be inserted in an extension header 364 before any pre-existing options including those previously inserted. 365 Similarly, if an extension header is being inserted and a 366 corresponding attribution option is being added to a Destination 367 Option extension header then the inserted extension header 368 immediately follows the Destination Options extension header and 369 precedes any previously inserted extension headers with an 370 attribution option in the same Destination Options extension header. 372 Inserted extension headers and inserted Hop-by-Hop and Destination 373 options MUST be removed in the reverse order of insertion (i.e. 374 inserted headers are "popped" to remove them). When an Attribution 375 Option is removed from a packet, which is the first option in the 376 extension header, the option, any corresponding inserted options, and 377 any inserted trailing padding are removed. In the case of a 378 Destination Options or Hop-by-Hop Options extension header that was 379 inserted, the inserted extension header is removed when when the last 380 attribution option in the extension header is removed (Num_opts in 381 the option is equal to 127). 383 The logical structure of an IPv6 packet with inserted extension 384 headers and options, and the relationship between Attribution Options 385 and inserted extension headers and options, is demonstrated below. 386 In this example, a Hop-by-Hop Options extension header was inserted 387 that indicates inserted Hop-by-Hop options. There are two 388 attribution options inserted into an existing Destination Options 389 header: the first one (#1) indicates an inserted extension header and 390 no options, the second (#2) indicates an inserted extension header 391 and also inserted Destination options. 393 +-+-+-+-+-+-+-+-+-+ 394 | IPv6 header | 395 +-+-+-+-+-+-+-+-+-+ 396 | Hop-by-Hop EH | 397 +-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Attribution Opt | 399 +-+-+-+-+-+-+-+-+-+-+ 400 | Inserted options | 401 +-+-+-+-+-+-+-+-+-+-+-+-+ 402 | DestOpt EH | 403 +-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Attribution Opt |---------+ #2 attribution option 405 +-+-+-+-+-+-+-+-+-+-+ | 406 | Inserted options | | 407 +-+-+-+-+-+-+-+-+-+-+ | 408 | Attribution Opt |----+ | #1 attribution option 409 +-+-+-+-+-+-+-+-+-+-+ | | 410 | Original options | | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+ | | 412 | Inserted EH |<---------+----+ 413 +-+-+-+-+-+-+-+-+-+ | 414 | Inserted EH |<------+ 415 +--+-+-+-+-+-+-+-+ 416 | Original EHs | 417 +-+-+-+-+-+-+-+-+-+ 419 3. Operation 421 This section describes operations for extension header and options 422 insertion and removal at intermediate nodes. 424 3.1. Insertion 426 An extension header or Hop-by-Hop or Destination options MAY be 427 inserted into a packet. The packet's size will increase, and if 428 options are inserted into Destination or Hop-by-Hop Options the size 429 of those extension headers will increase. 431 3.1.1. Insertion procedure 433 Hop-by-Hop and Destination options, including the attribution option, 434 are inserted into a packet with the following procedures. 436 Procedure is: 438 * If an appropriate Hop-by-Hop or Destination Options extension 439 header does not exist in the packet: 441 1) Insert a Hop-by-Hop or Destination Options extension header 442 into the packet at the appropriate offset. The extension 443 header contains the Attribution Option, followed by any Hop- 444 by-Hop or Destination options being inserted. Num_opts is 445 set to 127 to indicate that the extension header was 446 inserted. E is set if another extension header is also 447 being inserted (applicable to Destination Options). Add 448 padding to make the length of the extension header be a 449 multiple of eight bytes per [RFC8200]. 451 2) If no other extension header is being inserted then the 452 nexthdr of the inserted Destination or Hop-by-Hop header is 453 set to value of the nexthdr in the preceding IPv6 header or 454 extension header. 456 3) Else, if an extension header is being inserted then the 457 nexthdr of the inserted Destination Options extension header 458 is set to protocol number of the inserted extension header. 459 The nexthdr for the inserted extension header is set to 460 value of the original nexthdr in the IPv6 header or 461 extension header that precedes the Destination Option being 462 inserted. 464 4) The nexthdr of the IPv6 header or extension header that 465 precedes the inserted Destination of Hop-by-Hop Options is 466 set to the the protocol number for the inserted header 467 (either 0 for Hop-by-Hop Options or 60 for Destination 468 Options). 470 * Else, if an appropriate Hop-by-Hop or Destination Options 471 extension header is already present then insert new options 472 into the existing header: 474 1) Make first option to be the Attribution Option. Num_opts is 475 set to the number of non-padding options being inserted not 476 including the Attribution Option. E is set if an extension 477 header is being inserted (applicable to Destination 478 Options). 480 2) Following the Attribution Option, set any other options 481 being inserted. Include padding before the options as 482 necessary to enforce any alignment requirements. 484 3) Following the last inserted option, add the minimal amount 485 of padding such that the alignment of the first byte after 486 the last inserted byte is 8n+2 from the start of the Hop-by- 487 Hop or Destination extension header. This is necessary to 488 preserve alignment requirements of existing options. The 489 amount of padding needed is: 491 7 - ((offset_last_inserted_byte - 3) % 8) 493 4) Following the last inserted option and inserted padding, 494 copy the original options from the packet. 496 5) Set length of the Hop-by-Hop or Destination Options 497 extension header to reflect the length with the inserted 498 options and any inserted padding. 500 6) If an extension header is being inserted then the nexthdr of 501 the Destination Options header is set to protocol number of 502 the inserted extension header. The nexthdr for the inserted 503 extension header is set to is set to original nexthdr value 504 of Destination Options extension header. 506 3.1.2. Errors during insertion 508 Errors may occur in the process of inserting extension headers in a 509 packet. Error conditions would include the resultant packet size 510 exceeding MTU, and the size of Hop-by-Hop Options extension header 511 exceeding 1024 bytes (the maximum size of the Hop-by-Hop Options 512 extension header). 514 If an error occurs during insertion then the node performing 515 insertion MUST take an appropriate behavior per some configuration. 516 The packet MAY be discarded or the unmodified packet MAY be 517 forwarded. An error SHOULD be logged. 519 3.2. Removal of inserted extension headers and options 521 The top level inserted extension headers and Hop-by-Hop options, 522 referred to by the Attribution Option, which is precisely the first 523 option in the Hop-by-Hop Options for a packet, MAY be removed by an 524 intermediate node. 526 3.2.1. Removal procedure 528 The procedure is: 530 * If Num_opts equals 127 then the Destination or Hop-by-Hop 531 extension header is to be removed. 533 * If the E bit is not set or a Hop-by-Hop extension header is 534 being removed, remove the Destination or Hop-by-Hop 535 extension header bytes from the packet and set the nexthdr 536 of the preceding IPv6 header or extension header to the 537 nexthdr of the Destination or Hop-by-Hop Options extension 538 header being removed. 540 * Else, if the E bit is set in the attribution options of a 541 Destination extension header, remove the extension header 542 bytes of the following extension header from the packet. 543 The nexthdr of the preceding IPv6 header or extension header 544 to is set to the nexthdr of the Destination Options or Hop- 545 by-Hop Options extension header being removed. 547 * Else, if Num_opts is less than 127, then the inserted options 548 must be removed from the existing header: 550 1) Locate the last inserted option. This done by the scanning 551 non-padding options after the Attribution Option for the 552 count in Num_opts. 554 2) Compute the amount of padding that was inserted. The amount 555 of padding that should have been inserted is: 557 7 - ((offset_last_inserted_byte - 2) % 8) 559 where offset_last_byte is the offset of the last byte of 560 the last inserted option located in step #1. 562 3) Remove the bytes in the packet from first byte of the 563 Destination or Hop-by-Hop Options data (first byte of the 564 Attribution option) through the last byte of inserted 565 padding as computed in step #2. 567 4) Set the length of the Hop-by-Hop Options extension header to 568 account for the removed bytes. 570 5 If the E bit is set in the attribution option being removed 571 of a Destination extension header, remove the following 572 extension header from the packet. The nexthdr of the 573 Destination Options extension header is set to the nexthdr 574 of the extension header being removed. 576 3.2.2. Errors during removal 578 A node performing extension header removal MUST validate packet 579 contents. 581 The following attributes MUST be validated before removal: 583 * If Num_opts is not equal to 127 then number of non-padding 584 options following Attribution Option MUST be greater than or 585 equal to Num_opts. 587 * Necessary padding after the last inserted Hop-by-Hop option 588 MUST be present. The amount of padding MUST be equal to the 589 expected amount. 591 * The Num_opts options following the Attribution Option MUST NOT 592 contain another Attribution Option. 594 * If the E bit is set in the Attribution options of a Destination 595 Options header then the a valid extension header MUST follow 596 the Destination Options header. 598 If any of the above validations fail, or an error is otherwise 599 encountered in the removal process, then the processing node MUST 600 take action. The packet SHOULD be discarded and error message SHOULD 601 be logged. 603 3.3. Domain edge filtering 605 Filtering packets with inserted extension headers or Destination or 606 Hop-by-Hop options is straightforward: a packet contains inserted 607 options if the first option of Destination Options or Hop-by-Hop 608 Options is the Attribution Option. A packet contains inserted 609 extension headers if it contains an attribution option, either in 610 Destination Options or Hop-by-Hop Options, with Num_opts equal to 611 127; or it contains an attribution option in Destination Options that 612 has the E bit set. 614 3.4. ICMP processing 616 At described in [I-D.smith-6man-in-flight-eh-insertion-harmful], it 617 is possible for a source node to receive ICMP [RFC4443] errors caused 618 by inserted headers, thus the source node has no recourse to address 619 the error. 621 This section proposes some ways to apply the Attribution Option to 622 mitigate the ICMP breakage for extension header insertion: 624 * ICMP errors can be filtered [RFC4890] by nodes in the network 625 before reaching a source node outside of the domain (at the 626 domain edge for instance). The packet headers in the ICMP data 627 will include the Destination Options or Hop-by-Hop Options 628 extension header containing the Attribution Option. The 629 filtering node MAY analyze the error to determine if it was 630 caused by the inserted headers: 632 - If the error was caused by inserted extension headers, then 633 the node SHOULD take appropriate actions (minimally it 634 SHOULD log the error). The filtering node SHOULD not 635 forward the ICMP error to the source. 637 - If the error was not caused by inserted headers, the 638 filtering node MAY create a new ICMP error with the data 639 packet that would be reflect the packet contents prior to 640 extension header insertion (i.e. attempt set the packet in 641 ICMP to be that which the source would have sent). This is 642 done by removing the inserted extension headers of the 643 packet in the ICMP data, and adjusting the Pointer field in 644 an ICMP error if necessary. The revised ICMP error can then 645 be forwarded to the source. 647 * If ICMP errors are not filtered and the source node receives an 648 ICMP error for a packet containing inserted extension headers: 650 - If the source node is a legacy implementation that does not 651 understand the Attribution Option then it will attempt to 652 process the error under the assumption that it was the 653 source of the packet and the data that caused the error. If 654 the node logs the contents of the ICMP error, which should 655 be common, then external out-of-band analysis can be done by 656 network administrators to troubleshoot the ICMP errors and 657 identify culprit if the error was caused by inserted 658 extension headers. 660 - If the source node understands the Attribution Option then 661 it can perform more analysis. The node MAY attempt to 662 ascertain if the error was caused by inserted headers or 663 not, and if not it can then attempt to fix the problem with 664 the assumption the it was responsible for the data in error. 666 3.5. Processing AH 668 Extension headers and options MAY be inserted into a packet before an 669 existing AH header. The inserted data is not covered in the ICV 670 computation and if a receiving host attempts performs the ICV 671 computation with inserted data it is expected that verification will 672 fail and the packet will be dropped. 674 The simplest way to address this is to remove any inserted headers in 675 the packet before processing the AH extension header. The assumption 676 is that once the inserted data is removed the packet contents reflect 677 the original contents set by the host so AH verification should 678 succeed. 680 Host implementations can be modified to process the attribution 681 option. When a packet with inserted headers or options is received 682 by an end host the AH processing can ignore any inserted Destination 683 or Hop-by-Hop options and any inserted extension headers. This can 684 be done in conjunction with the existing algorithms to ignore option 685 data in the ICV computation for modifiable options. Effectively, the 686 algorithm is simply to remove all the inserted options and extension 687 headers following the procedures in section 3.1. 689 4. Security Considerations 691 The Attribution Option does not in itself introduce any new security 692 considerations. The security of containing inserted extension 693 headers within a controlled domain is out of scope for this document. 695 Section 3.5 describes the processing of the IP Authentication Header 696 in the presence of inserted options or extension headers. 698 5. IANA Considerations 700 IANA is requested to assigned the following Destination and Hop-By- 701 Hop option: 703 +-----------+---------------+-------------+---------------+ 704 | Hex Value | Binary value | Description | Reference | 705 | | act chg rest | | | 706 +-----------+---------------+-------------+---------------+ 707 | TBD | 00 0 TBD | Attribution | This document | 708 | | | Option | | 709 +-----------+---------------+-------------+---------------+ 711 6. References 713 6.1. Normative References 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, 717 DOI 10.17487/RFC2119, March 1997, 718 . 720 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 721 DOI 10.17487/RFC4302, December 2005, 722 . 724 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 725 Control Message Protocol (ICMPv6) for the Internet 726 Protocol Version 6 (IPv6) Specification", STD 89, 727 RFC 4443, DOI 10.17487/RFC4443, March 2006, 728 . 730 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 731 (IPv6) Specification", STD 86, RFC 8200, 732 DOI 10.17487/RFC8200, July 2017, 733 . 735 6.2. Informative References 737 [I-D.ietf-ippm-ioam-ipv6-options] 738 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 739 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 740 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 741 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 742 ipv6-options-01 (work in progress), March 2020. 744 [I-D.smith-6man-in-flight-eh-insertion-harmful] 745 Smith, M., Kottapalli, N., Bonica, R., Gont, F., and T. 746 Herbert, "In-Flight IPv6 Extension Header Insertion 747 Considered Harmful", draft-smith-6man-in-flight-eh- 748 insertion-harmful-02 (work in progress), May 2020. 750 [I-D.voyer-6man-extension-header-insertion] 751 Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy, 752 J., Li, Z., and J. Guichard, "Deployments With Insertion 753 of IPv6 Segment Routing Headers", draft-voyer-6man- 754 extension-header-insertion-09 (work in progress), May 755 2020. 757 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 758 ICMPv6 Messages in Firewalls", RFC 4890, 759 DOI 10.17487/RFC4890, May 2007, 760 . 762 Author's Address 764 Tom Herbert 765 Intel 766 Santa Clara, CA 767 USA 769 Email: tom@quantonium.net