Reviewer: Gorry Fairhurst Review result: Not Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. Review for "Limits on Sending and Processing IPv6 Extension Headers" The document seeks to provide informational guidance on how to best configure limits to IPv6 Extension Header processing. It seems to provide two contributions: - It seeks to ossify the IPv6 header structure, by suggesting to deploy checks in routers and other nodes that drop packets when they do not conform. - It seeks to recommend values for the size and number of extensions/options that may be expected to be included in an IPv6 packet. The two contributions together seek to ease deployment of some types of extension, by specifying minimum expectations. On the one hand, if deployed this would ease section of appropriate sized header chains by endpoints that would increase the chance of successful use across an end-to-end path. One advantage of this approach is that it could encourage greater deployment of in-network and stack support for extension headers. On the other hand, this would also result in discard of packets that include extension headers that do not conform (in size or structure). This will prevent other (new) types of extension. If published, it will likely have the impact of ossifying IPv6 around these constraints, this will simplify the design, but thought is needed around how to evolve to add different features in future. The document discusses extension header use at end hosts, by routers, by middle boxes, firewalls and devices performing operations such as ECMP. Although an INT area specification, this has impact on whether an endpoint is able to include destination and HBH options in packets that it sends, and therefore it impacts has implications on the transport, which includes methods such as racing, the use of tunnels/encapsulation by the end-to-end transport, and methods such as OAM. It also impacts the design of middle boxes. In summary, I think the draft is not ready for publication. This document has several major issues. In all text below, the word "OLD" refers to the reviewed revision of the I-D. General Review Comments: 1. Use of RFC 2119 Language This draft contains RFC 2119 requirements language, which maybe is not needed in an INFO document. I’d suggest using only lower case terms, which would also remove the burden of proof that these are the correct terms in each case. 2. The I-D refers to itself as a specification in multiple places. For example: OLD: This specification includes limits on extension headers NEW: This document includes limits on extension headers --- - This reviewer suggests to use the word “document” throughout, because this is to be published as Informational. 3. The appendix needs clearer scope to provide only the required background information, not reiterate requirements. In the Annexe, OLD: This scheme thus establishes a requirement that Internet devices must be capable of correctly processing packets with up to sixty-four bytes of extension headers, and subsequently it establishes a requirement that a host shouldn't send packets with more than sixty- four bytes of extension headers unless it known that all the nodes in the path can process packets with larger extension headers and a larger IPv6 header chain. Note that this establishes a global minimum baseline requirement across the Internet; within a limited domain higher limits could freely be applied. --- - This language seems excessively strong for informational documentation. - I would hope it establishes an expectation that Internet devices are able to process packets. - It does not set requirements, but it could give very useful guidance. - If published this guidance might be expected to become the norm, which will ossify (significantly limit) the ability to change in future. ========= Major issues: 1. This is an INT Area spec twith text that appears to speak about middleboxes, firewalls etc, but doesn’t really say so or discuss how they ought to operate. In particular the text motivates that routers ought to be able to interpret the transport headers: “If a router needs to parse the upper layer protocol, for instance to deduce the transport layer port numbers, it MUST be able to correctly forward packets that contain an IPv6 header chain of 104 or fewer bytes, or equivalently, a router MUST be able to process a packet with an aggregate length of extension headers less than or equal to 64 bytes. " In the Appendix, OLD: A de facto requirement of many routers is that they need to process transport layer headers in packets. --- - I think this needs more clarification, and specifically ought to note the implications of performing deep packet inspection and mitigations there are to avoid this (see note on at least discussing the flow table as one remedy for ECMP). - The growing use of VPN and other encryption makes this particularly short-sighted. Although perhaps noting the intent of the flow label might help in such an argument to mitigate the ossification around using transport information in the network. 2. Please check the relationship to the recently published RFC 9673 OLD: Routers are susceptible to the attack using Hop-by-Hop options, hosts are susceptible using Hop-by-Hop options or Destination options, and intermediate nodes are susceptible using Hop-by-Hop options or Destination options before the Routing Header. --- - - This seems to be no longer true after publication of RFC 9673, “IPv6 Hop-by-Hop Options Processing Procedures”, making HBH options skippable. RFC 9673 also sets configuration control that permits: “A configuration could control whether normal processing skips any or all of the Hop-by-Hop options carried in the Hop-by-Hop Options header.” 3. The following comments relate to changes that update the text of RFC8200, in terms of the structure of the header chain. This is a full standard, and there is no updates field to indicate there are changes to the specification of RF8200 (which might otherwise be a DOWN REF for an Informational I-D to makes new stronger rules for processing than currently defined in a standard). When I reviewed the I-D, The document does not explain how these proposed changes were analysed or motivated. See below: 3.1 Would update RFC 8200 processing order of extension headers: OLD: A host or intermediate MAY enforce the recommended extension eader ordering and number of occurrences of extension headers described in Section 4.1 of [RFC8200]. Per the ordering recommendations, each extension header can occur at most once in a packet with the exception of Destination Options header which can occur twice. ---. and OLD: If a host or intermediate node enforces extension header ordering and a packet is received with extension headers out of order or the number of occurrences of an extension header is greater than one, or two for the Destination Options header, then the receiving node SHOULD discard the packet and MAY send an ICMP Parameter Problem message with code 8 (Too Many Extension Headers) [RFC8883] to the packet's source address. ---. and OLD: Note that a host may enforce extension header ordering for all extension headers in a packet, but an intermediate node may only enforce ordering for extension headers up to and including the Routing Header. --- - RFC 8200, section 4.1, makes non-normative statements about the ordering of extension headers: RFC 8200: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: ... --- - RFC 8200 the continues to say: “If and when other extension headers are defined, their ordering constraints relative to the above listed headers must be specified” and RFC8200 states: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. --- - Therefore this I-D, if published, will change these recommendations by suggesting a different set of rules for processing, or at least would change the non-normative expectation of this full standard. - From a transport perspective, enforcing extension header ordering for extension headers included in a packet within an intermediate seems like it is a new obstacle for incremental deployment. 3.2 This would update RFC 8200 with new stronger rules for the number of times an extension header can appear, restricting what is currently allowed. RFC 8200: Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header). --- - - Is there evidence (I did not see a reference) that says whether this will cause more paths to drop packets, or whether this is expected to encourage more paths. Is there any measurement data? - From a transport perspective: Enforcing extension header ordering for extension headers included in a packet within an intermediate seems like it is a potential obstacle for incremental deployment. 3.3 This would change the method in RFC 9673, which motivates skipping unknown or un-configured HBH options. OLD : It is NOT RECOMMENDED that the router discards the packet because the limit is exceeded, however if it does then the router MAY send an ICMP Parameter Problem message --- and OLD: If a packet is received and the number of Destination or Hop-by-Hop options exceeds the limit, then the receiving node SHOULD discard the packet and MAY send an ICMP Parameter Problem message with code 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. --- - It seems to change the expectation in RFC 9673 by specifying different rules when more HBH options within an EH than expected (i.e., it says “not recommended” rather than RECOMMENDED to skip). This change appears to create more opportunities for path failure (discard of packets by a path), was this change intended? 3.4 If published, this would update RFC 8200 with new stronger rules for generating ICMPv6 messages. - In various places there is text about optionally generating ICMPv6 messages, whereas RFC8200 seems to indicate nodes should generate ICMP messages when packets are discarded. This could be OK, but is there a reference to support this rule? OLD: It is NOT RECOMMENDED that the router discards the packet because the limit is exceeded, however if it does then the router MAY send an ICMP Parameter Problem message --- - There was a general principle that packet discard should result in ICMPv6 messages indicating the problem encountered, which seems to be what RFC8200 states. It is not the case that endpoints expect to see these messages, none-the-less this isn’t a PS and therefore this should likely point to the RFC that describes when ICMPv6 is used. 4. The following new rule partly seems to contradict another new rule in this I-D: OLD: If a limit is exceeded, routers SHOULD still forward the packet and SHOULD NOT drop packets because a limit is exceeded. --- The conflict is with, OLD: A router MAY disallow consecutive padding options, either PAD1 or PADN, to be present in the Hop-by-Hop Options header. If a packet is received with consecutive padding options that are disallowed by the router, then the router SHOULD stop processing the Hop-by- Hop Option header and ignore any Hop-by-Hop options beyond the limit. It is NOT RECOMMENDED that the router discards the packet because the limit is exceeded, however if it does then the router MAY send an ICMP Parameter Problem message with code 7 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. --- - Could this rule be changed to “Routers ought to forward packet when the limit is exceeded” - In which case, ought they not also to skip the remaining options and process the packet, which might involve processing additional extension headers? 5. Why is the rule about only one PAD option needed? OLD: A source host SHOULD NOT set more than one consecutive pad option, either PAD1 or PADN, in a Destination Options header or Hop-by-Hop Options header. --- and later , OLD: host or intermediate node MAY disallow consecutive padding options, either PAD1 or PADN, to be present in a packet. If a packet is received with consecutive padding options that are disallowed by the receiving node, then the receiving node SHOULD discard the packet and MAY send an ICMP Parameter Problem message with code 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. --- and OLD: In addition to a limit on the number of consecutive bytes of padding, this specification allows a receiver to disallow consecutive padding options. The rationale is that a single PAD1 or PADN option can be used to provide 1 to 257 bytes of padding which is sufficient for any practical use case. Correspondingly, this specification also recommends that a sender does not send a packet with consecutive padding options. --- - Why is it necessary that this restriction on PAD processing is needed? - It was previously allowed to send multiple PAD options (albeit with no upper limit on the total number of options). For testing, a sender could replace an option with a PAD, but that could result in more than one PAD option, which could with the new I-D cause the packet to be discarded. - Is there an important reason why the limit of 8 options cannot include more than one PAD option? 6. Does that mean a host becomes restricted in how it can use destination options end-to-end when it includes (for example SRV) extension header? OLD: A source host SHOULD NOT send a packet with an IPv6 header chain larger than 104 bytes unless it has explicit knowledge that all possible routers, intermediate nodes, and the destination host in the path are able to process a larger IPv6 header chain. If a packet contains an IPsec header then this limit only applies through the end of the IPsec header (the IPsec header obfuscates following headers so that they are unreadable by nodes in the path). This requirement is equivalently stated as a host SHOULD NOT send a packet with more than 64 bytes of aggregate extension headers. --- - Does this have implications at the transport layer on what destination and HBH options can be sent? The problem I fail to understand is how the processing on the path impacts the choices available at the endpoints, especially if the set of EH are not delivered to the final transport endpoint. - Restrictions arising from a need for visibility of the transport header seem a significant change to the IPv6 specification. For a packet that includes a routing header or other extension header used on a part of the path, it then appears to limit what options/size the host can use end-to-end across the transport connection. Similarly, the document does not discuss the addition of extension headers for purposes such as OAM, which I also assume that an endpoint needs to discover before it adds extensions - since network paths might then “police” the overall header chain? - How do these restrictions apply to the processing of packets that include an IPSEC header, tunnel extension, or something similar that relate to all or a part of the path being used? How does the sending endpoint discover this limit that appears on-path? It seems the only way to evolve and use new headers is for the transport to use a method that would deliberately hide the extension headers from the routers on the path (as in IPsec currently), which appears to prevent access on the path to the transport header (which was one of the motives of this proposal). Please calrify how this evolution will play out. 7. I have concerns about the completeness of the analysis of the currently deployed support (see Appendix). This could be remedied by citing and comparing a range of sources. It is generally unwise to base decisions on presentations, and I would encourage a wider set of sources (single point measurements are prone to bias from using a specific vantage point from which to measure - which is the topic of [Cus23a]). Please use archived journal publications (where the scientific rigour/review helps support the claims and the methodology is clear). 8. The document is complex and can have significant impacts of the ability for IPv6 to evolve. This document includes both restrictions to the structure of extension headers (e.g. the ordering) and recommendations of the size of extension headers. I can see significant merit in reviewing whether both of these changes are necessary, and if they are both needed, then to place these in separate documents. ========= Comments related to the document structure/editorial: 1. Including Extension Headers I recall the appropriate language concerning extension headers is to describe this as “packets that include extension headers”, as per RFC 8200. 2. In the abstract, OLD: The need for such limits is pragmatic to facilitate interoperability amongst hosts and routers in the presence of extension headers, thereby increasing the feasibility of deployment of extension headers. --- - This sentence was difficult to read and distill. I’d have understood this quicker, if I understood the goal was to introduce limits that can improve the deployability of extension headers, or something similar. 3. OLD: The lack of limits and the requirements for supporting a virtually open-ended protocol have led to a significant lack of support and deployment of extension headers ([RFC7872], [Cus23b]). Suggested NEW: The lack of limits and the requirements for supporting a virtually open-ended protocol have led to a current lack of support and deployment of extension headers ([RFC7872], [Cus23b]). --- - I am always super-wary about making statements about significance and level of support in the RFC series. As an archived document it seems better not to judge a “significant lack of support” without qualifying that this is the current state at the time of writing. Too often, a claim is re-cited in other places and for other reasons so I would encourage this to be qualified by at the time of writing and to remove the word “significant”. 4. OLD: The net effect of this situation is that deployment and use of extension headers is underwhelming to the extent that they are sometimes considered unusable on the Internet, and hence IPv6 extension headers have not lived up to their potential as the extensibility mechanism of IPv6. --- - This appears overtly negative. As above, I’d strongly encourage the sentence to be re-phrased. Could it simply state the clear benefit that arises from deployable methods? 5. OLD: As an example, consider that there is no limit on how many Hop-by-Hop or Destination options may be in an extension header in a packet, nor any limits as to how many options a receiver must process. --- - This seems to be a statement about current deployment. Could the word “currently” be added? 6. OLD: Any node in the path that attempts to dutifully process all these options could be easily overwhelmed by the processing needed to parse these options, hence this is an effective DOS attack. Suggested NEW : A node on the path that attempts to process all options could become overwhelmed by the processing needed to parse these options, resulting in a vulnerability that could be exploited by a DOS attack. --- - “an effective…attack” seems an odd way to describe a vulnerability that could be currently exploited. I expect this could be rephrased, perhaps similar to what is suggested above? 7. Section 2 , OLD: limited is exceeded then the router skips NEW: limit is exceeded then the router skips --- - This seems to be a statement about current deployment. There is a possible typo in the current text? 8. OLD: The rationale is that the only extension header a router may process is Hop-by-Hop Options and the packet can be correctly forwarded if none or some of the Hop-by-Hop options are processed. --- - Partly true, but I note that intermediate nodes process Segment Routing Headers. Maybe the text could be updated? 9. In Appendix: A.2. Limits on length OLD: The 104 byte limit is derived from an assumed parsing buffer size of 128 bytes. --- - This seems to be a statement about current deployment. I’d suggest to say “At the the time of writing….” 10. In Appendix: A.2. Limits on length, OLD: The default IPv6 header chain limit is derived from the expected size of parsing buffers assuming that there is space to accommodate the first bytes of the transport layer header in the parsing buffer. --- - I’d suggest to say “At the the time of writing….” 11. In Appendix: A.2. Limits on length, OLD: N ote that limit on seven consecutive bytes of padding is "hardcoded" and enforced in the Linux networking stack. --- - - I’d suggest to say “At the the time of writing….” 12. OLD: Security issues with IPv6 extension headers are well known and have been documented in several places including [RFC6398], [RFC6192], [RFC7045], [RFC4942], and [RFC9098]. ---. - Please also add a reference to the security discussion in RFC 9673. 13. In the para starting “A host or intermediate node MAY set a limit on the maximum length” two terms are used: “ aggregate length of extension headers in a packet” and " IPv6 header chain “ - - Please could this be rewritten to use just one term? 14. In Annexe, OLD: … A receiver attempting to process all the options in such packet would require a lot of resources as TLV processing is notoriously difficult to do efficiently. The potential for this DOS attack exists routers, hosts, and intermediate nodes. Routers are susceptible to the attack using Hop-by-Hop options Sugegsted NEW: … A receiver that attempts to process all the options in such packet would incur significant processing (e.g., TLV processing can be difficult to efficiently implement). This DOS vulnerability could exist in routers, hosts, and intermediate nodes. --- - I think this text could be improved - Elsewhere I don’t think the is called a “receiver”? - The words “lot of” and “notoriously” both would be better replaced. (see example new starting text). ===END=== -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
