idnits 2.17.1 draft-smith-6man-in-flight-eh-insertion-harmful-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2019) is 1661 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4271' is mentioned on line 138, but not defined == Missing Reference: 'RFC1122' is mentioned on line 309, but not defined == Missing Reference: 'RFC6272' is mentioned on line 309, but not defined == Missing Reference: 'RFC3031' is mentioned on line 364, but not defined Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft October 8, 2019 4 Intended status: Best Current Practice 5 Expires: April 10, 2020 7 In-Flight IPv6 Extension Header Insertion Considered Harmful 8 draft-smith-6man-in-flight-eh-insertion-harmful-00 10 Abstract 12 In the past few years, as well as currently, there have and are a 13 number of proposals to insert IPv6 Extension Headers into existing 14 IPv6 packets while in flight. This contradicts explicit prohibition 15 of this type of IPv6 packet proccessing in the IPv6 standard. This 16 memo describes the possible failures that can occur with EH 17 insertion, the harm they can cause, and the existing model that is 18 and should continue to be used to add new information to an existing 19 IPv6 and other packets. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 10, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. In-Flight Extension Header Insertion Defined . . . . . . . . 3 59 3.1. In-Flight Insertion . . . . . . . . . . . . . . . . . . . 3 60 3.2. In-Flight Removal . . . . . . . . . . . . . . . . . . . . 3 61 4. EH Removal Failure Causes . . . . . . . . . . . . . . . . . . 4 62 4.1. Implementation Bugs . . . . . . . . . . . . . . . . . . . 4 63 4.2. Partial Node Failure . . . . . . . . . . . . . . . . . . 4 64 4.3. Operator Configuration Error . . . . . . . . . . . . . . 4 65 5. Single Point of Failure . . . . . . . . . . . . . . . . . . . 5 66 6. MUST Remove is Aspirational . . . . . . . . . . . . . . . . . 5 67 7. Harm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Violates RFC8200 and All Of Its Ancestors. . . . . . . . 5 69 7.2. Ignores Source Address Field Semantics . . . . . . . . . 5 70 7.3. Breaks ICMPv6 . . . . . . . . . . . . . . . . . . . . . . 5 71 7.3.1. Breaks PMTUD . . . . . . . . . . . . . . . . . . . . 5 72 7.4. Breaks IPsec . . . . . . . . . . . . . . . . . . . . . . 6 73 7.5. May Confuse Destination Node . . . . . . . . . . . . . . 6 74 7.6. May Cause Faults in Subsequent Transit Networks . . . . . 6 75 7.7. Implementation Complexity . . . . . . . . . . . . . . . . 6 76 8. Be conservative in what you send, ... . . . . . . . . . . . . 7 77 9. Solution: Encapsulation . . . . . . . . . . . . . . . . . . . 7 78 9.1. IPv6 Tunnelling . . . . . . . . . . . . . . . . . . . . . 8 79 9.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 10. In-Flight Insertion Considered Harmful . . . . . . . . . . . 9 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 83 13. Change Log [RFC Editor please remove] . . . . . . . . . . . . 9 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 14.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 14.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Terminology 99 o In-Flight - the state of a packet while it is travelling throught 100 the network between its original source IPv6 and final destination 101 IPv6 hosts. The packet will be being forwarded along a series of 102 hops along a set of IPv6 routers interconnecting the source and 103 destination IPv6 hosts. 105 o 107 3. In-Flight Extension Header Insertion Defined 109 3.1. In-Flight Insertion 111 At a point somewhere along the path an IPv6 [RFC8200] packet travels 112 between the packet's source IPv6 host, identified in the packet's 113 Source Address field, and the packet's final IPv6 destination host, 114 identified in the packet's Destination Address field, the packet is 115 split apart after the IPv6 fixed header and before the packet 116 payload. Then, one or more new Extension Headers (EHs) [RFC8200] are 117 inserted between those two existing packet parts. The new EH or EHs 118 may be the sole EH or EHs in the packet after insertion, or it, or 119 they, may be inserted at the start, within, or after the packet's set 120 of original EHs. 122 The packet's original source and Destination Address field values are 123 left unchanged when EH insertion takes place. It is likely that 124 other immutable fields of the IPv6 header are also left unchanged, 125 with possible exception to the immutable Next Header field [RFC8200] 126 if the inserted EH or EHs are inserted directly after the IPv6 fixed 127 header. 129 For IPv6 tunnel packets [RFC2473], where they may be two or more 130 instances of an IPv6 fixed header throughout the packet, EH insertion 131 could be occurring between any of the IPv6 fixed headers and their 132 respective following payloads, although it is most likey to occur 133 after the first of the IPv6 fixed header, commonly known as the 134 (outer) tunnel header. 136 An example of where this in-flight EH insertion may take place is 137 when a packet enters a transit BGP autonomous system network 138 [RFC4271] along its path across the Internet. 140 3.2. In-Flight Removal 142 At some later point along the IPv6 packet's path towards its final 143 destination, the packet is somehow determined to need to have the 144 prevously inserted EH removed. The packet is again split apart, at 145 the point where the one or more inserted EHs exists, and then the 146 inserted EH or EHs are removed. The packet is then reassembled, and 147 sent further towards its final destination. 149 Again, the packet's original source and Destination Address field 150 values are left unchanged when EH removal takes place. As with 151 insertion, the likely only IPv6 fixed header field modified during EH 152 removal would be the immutable Next Header field. 154 An example of where this in-flight EH removal would take place is 155 when a packet leaves a transit BGP autonomous system network that has 156 previously inserted one or more EHs. 158 4. EH Removal Failure Causes 160 4.1. Implementation Bugs 162 Despite being configured to remove the inserted one or more EHs, an 163 implementation bug could cause some or all packets not to have the 164 inserted EH or EHs removed. 166 4.2. Partial Node Failure 168 Even though the software or firmware that is to perform EH removal is 169 bug free, it is possible that a hardware fault could cause EH removal 170 to not occur, while packets are still sent towards their final 171 destinaton. This could occur because the hardware fault that does 172 not cause the node to entirely fail, only partially performing some 173 of its functions.. 175 4.3. Operator Configuration Error 177 Due to human error, the function to remove the inserted EH or EHs may 178 be misconfigured. Consequently, the inserted EH or EHs may not be 179 removed for some or all packets. 181 When the packets to have the EH(s) removed are transit packets, 182 meaning these packets are likely leaving the operator's own network, 183 and entering another operator's network, it is less likely that the 184 packets leaving are inspected to ensure the EH removal function has 185 been configured correctly. It is common to assume that if traffic is 186 leaving the local network in the expected volumes, then the traffic 187 is being processed correctly by the egress network device. This can 188 be because the equipment, time and effort to validate this egressing 189 traffic can be very expensive when traffic volumes are in the 10s or 190 perhaps 100s of gigabits per second. 192 The receiving network will also not detect or be able to detect that 193 the inserted EHs have not been removed, as the inserted EH or EHs 194 will appear to have been placed in the packet by the IPv6 host 195 identified in the packet's Source Address field. 197 5. Single Point of Failure 199 When functions that inspect or modify packets beyond standard IP 200 packet forwarding are performed at the edge of a network, such as a 201 network firewall or a Network Address Translation, it is typical for 202 there to only be one device performing that will perform this 203 function at the packets' exit from the network. It is rare to have 204 two devices in-line or in series that are performing this same 205 inspection or modification, providing redundancy for the function 206 should it fail to be performed correctly at the first function 207 instance. 209 In a scenario where EHs are to be removed, it is likely that the 210 device that is to perform EH removal will be a single point of 211 failure. 213 6. MUST Remove is Aspirational 215 RFCs/IDs say the inserted EH MUST be removed at the EH insertion 216 boundary, and then use that to say it is a safe operation. This is 217 ignoring the reality of all of the above possible causes of an 218 inserted EH failing to be removed. Such a MUST statement is no more 219 than aspirational - it is a theoretically true statement in 100% of 220 cases, but in practice cannot ever be assured to be true in 100% of 221 cases, due to the removal failure causes, described previously. 223 7. Harm 225 7.1. Violates RFC8200 and All Of Its Ancestors. 227 (RFC8200 EH processing text quote) 229 RFC 2460 and ancestors back to RFC 1883 text quote. 231 7.2. Ignores Source Address Field Semantics 233 7.3. Breaks ICMPv6 235 7.3.1. Breaks PMTUD 236 7.4. Breaks IPsec 238 7.5. May Confuse Destination Node 240 7.6. May Cause Faults in Subsequent Transit Networks 242 If inserted EH is not removed, and the packet travels into another 243 subsequent transit network, that subsequent transit network may have 244 an alternative interpretation of the inserted EH, causing a fault. 246 The subsequent transit network, if using EH insertion, would likely 247 blindly insert another instance of the EH, resulting in a packet with 248 two EHs. At network egress, the incorrect EH may removed, which 249 would also still leave a remaining inserted EH to travel into further 250 subsequent networks. A directly subsequent network that is also 251 performing EH insertion is unlikely to act as a sanitser for EHs that 252 were inserted by previous upstream networks. 254 7.7. Implementation Complexity 256 IPv6 uses a packet's Destination Address to determine the point where 257 forwarding across the network stops, and processing up the protocol 258 stack at a destination host starts. 260 In other words, the Destination Address of a packet identifies the 261 point in the network where processing of the packet starts going 262 beyond the IPv6 fixed header, and where the intention of the packet 263 processing stops being limited to forwarding towards the packet's 264 destination. 266 This is the fundamental distinction between an IPv6 router and a 267 host; an IPv6 router forwards packets with non-local addresses 268 [RFC8200], while an IPv6 host, with that holds address that matches a 269 packet's Destination Address, processes the packet locally, with 270 processing occuring beyond the IPv6 packet's fixed header. Note that 271 these definitions of IPv6 router and host are functional; a router as 272 a device implements both IPv6 router and host functions - the 273 device's forwarding plane implementing the IPv6 router function, and 274 the device's control plane implementing IPv6 host functions. 276 This means that all IPv6 addresses that appear in an IPv6 packet's 277 Source Address and Destination Address field are, without exception, 278 host addresses. 280 The decision as to whether to process the packet beyond the fixed 281 header or not is binary and simple - does the current node holding 282 the packet possess the IPv6 address recorded in the Destination 283 Address field of the packet? 284 Identifying packets that have had EH's inserted, to then remove and 285 process the EH, is much more complex than the simple, Destination 286 Address match selector. The EH chain inside each packet has to be 287 processed to find the EH that was inserted, should it exist. 289 8. Be conservative in what you send, ... 291 i.e. Postel's law 293 "Be conservative in what you send, ..." is saying try to avoid 294 sending anything that the receiver may not be expecting and that may 295 confuse the receiver. The "be liberal in what you accept" is 296 advising robustness to attempt to tolerate a sender that has failed 297 to be conservative. 299 In-flight EH insertion violates the conservative sender part, because 300 [RFC8200] compliant receivers are not expecting to receive EHs in a 301 packet that were not placed there by the device identified in the 302 packet's Source Address field. A device performing in-flight EH 303 insertion is intentionally not being conservative with what it is 304 sending, in comparison to the scope of what an [RFC8200] compliant 305 receiver expects to receive. 307 9. Solution: Encapsulation 309 In the Internet Protocol Architecture [RFC1122][RFC6272], adding new 310 information to an existing protocol data unit is achieved through 311 encapsulation. The new information is recorded in a new header and 312 possibly a new trailer, which are then used to surround or enclose 313 the existing protocol data unit, similar to how an envelope is used 314 to enclose the contents of a letter in the physical mail system. 316 In addition to other new information, the new encapsulation header 317 records the source of that new information. For the link-layer that 318 is the source node's link-layer address; for the IP layer it is 319 either the IPv4 or IPv6 source host's address; and for the transport 320 layer, it is the source transport layer port, or some other transport 321 layer source entity identifier. 323 The new encapsulation also records the destination entity or entities 324 that is or are intended to receive and process the new information. 325 For the link-layer, the destination node's link-layer address, or a 326 single group address that identifies a set of link-layer nodes; for 327 the IP layer, the IPv4 or IPv6 destination host, or a single group 328 address that identifies a set of hosts; and for the transport layer, 329 the destination transport layer port or other transport layer 330 destination entity identifier. 332 The source and destination entity identification in the encapsulation 333 header provides unambiguous and explicit identification of both which 334 entity created and sent the new information, and which entity or 335 entities are to process the new information. 337 9.1. IPv6 Tunnelling 339 If additional IPv6 information is to be added to an existing IPv6 340 packet while it is in-flight, such as a new Extenstion Header, then a 341 new IPv6 header is required. This new IPv6 header will unambiguously 342 record the identity of the IPv6 host that has added the new IPv6 343 information in the Source Address field, and will unambigously record 344 the identity of the IPv6 host (or group of hosts) that is to process 345 the added IPv6 information in the Destination Address field. A new 346 IPv6 packet is created using the new IPv6 header, followed by the new 347 supplimentary information, followed by the existing IPv6 packet, 348 appearing in the payload field of the new packet. IPv6-in-IPv6 349 encapsulation is commonly known as "tunneling", and is specified in 350 [RFC2473], which includes showing how new information added via 351 Extension Headers occurs. [intarea-tunnels] provides more discussion 352 of IP tunneling in the context of the Internet Architecture. 354 Conceptually, IPv6-in-IPv6 tunneling is a form of link-layer 355 encapsulation from the perspective of the existing (and eventually 356 inner) IPv6 packet. It just happens to be a coincidence that the 357 outer link-layer encapsulation header and other new information (i.e. 358 Extension Headers) has the same protocol format and field sematics as 359 the existing, inner IPv6 packet. 361 9.2. MPLS 363 Despite using terms such as "label imposition" or "label swapping", 364 MPLS [RFC3031] also follows this encapsulation model to add new 365 information, via labels, to an existing in-flight protocol data unit, 366 such as an IPv6 packet. In-flight insertion of MPLS labels never 367 occurs. 369 At each hop through the MPLS network where labels are processed, at 370 devices known as Label Switching Routers (LSRs), upon egress from the 371 LSR, a new link-layer header is created that both unambiguously 372 identifies the current LSR in the link-layer Source Address field, 373 and unambiguously identifies the next LSR (or set of LSRs) that is to 374 process the set of labels that are encoded in the link-layer protocol 375 data unit sent by the current LSR. The labels are encoded following 376 this new header, and then the original packet follows in the link- 377 layer payload field. 379 If in-flight MPLS label insertion were to be actually occurring, then 380 it would mean that as a packet was label switched across a set of 381 LSRs along a Label Switched Path (LSP), the link-layer header Source 382 Address would not change across the LSP - it would remain as the 383 Source Address of the LSR at the head end of the LSP, regardless of 384 how many subsequent LSRs the packet is label switched through. 386 In-flight MPLS label insertion would also mean that the Destination 387 Address in the link-layer header would also not change as the packet 388 is label switched along the LSP. It would remain unchanged 389 regardless of how many LSRs the packet traverses, and would likely 390 identify the final LSR at the tail end of the LSP. 392 If MPLS had used an in-flight insertion model, then MPLS would have 393 likely suffered from problems similar to those described above that 394 can occur with IPv6 EH insertion. 396 10. In-Flight Insertion Considered Harmful 398 More generally, insertion within an existing, in-flight packet at any 399 location within the packet is considered harmful. EH insertion, as 400 described and discussed previously, is a more specific instance of a 401 harmful practise. 403 11. Security Considerations 405 12. Acknowledgements 407 Review and comments were provided by YOUR NAME HERE! 409 This memo was prepared using the xml2rfc tool. 411 13. Change Log [RFC Editor please remove] 413 draft-smith-6man-in-flight-eh-insertion-harmful-00, initial version, 414 2019-09-XX 416 14. References 418 14.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 426 (IPv6) Specification", STD 86, RFC 8200, 427 DOI 10.17487/RFC8200, July 2017, 428 . 430 14.2. Informative References 432 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 433 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 434 December 1998, . 436 Author's Address 438 Mark Smith 439 PO BOX 521 440 HEIDELBERG, VIC 3084 441 AU 443 Email: markzzzsmith@gmail.com