Gorry, This review is way too long for me to process easily. Can you provide the diffs between versions? Also can you remove things that are settled. For instance, there is plenty of precedent that RFC2119 language can be used in an Informational RFC, especially RFC6434. Can you withdraw those comments? I think you are reading this draft too much from a theoretical perspective and not enough from a pragmatic perspective. This draft is pragmatic to make Extension Headers deployable in the world. In particular, several times in the review you state that this draft could ossify IPv6, significantly limit the ability to change the future, ossify the IPv6 header structure, significant impacts of the ability for IPv6 to evolve, and so on. Those are very scary and alarming words! But they're use is also misguided. The problems you're concerned about _already_ exist in the real world. The idea that implementers just read the spec and implement that exactly is a fantasy, we need to make a practical implementation based on the spec which sometimes won't conform and that's where ossification begins. So the purpose of this draft isn't to exacerbate the problem, but to address it by acknowledging that nodes don't have an infinite number of resources to process every conceivable combination. For example, RFC8200 states that a host must process any number of extension headers in a packet. That requirement is simply *not* feasible. Someone could stuff over 150 Destination Options headers into a single packet filled with nothing but padding. That is a _lot_ of processing on a host and with no effect-- the only purpose of this is DoS attack. So we need to limit the number of EH headers (avoiding DoS is a real problem, the off chance that someone may come up with a valid use case of more than even one Destination Option header in a packet much less a hundred of them is not enough to warrant high limits). So whether or not this draft is published, host stacks are going to put limits on extension headers. IMO, providing consistent guidance on how to do that is far better than letting everyone decide what to do on their own. Tom On Sun, Dec 1, 2024 at 1:57 AM Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote: > > Tom, > > Thanks for taking the care to read and respond to the review. > > I normally review starting from the I-D, not the working groupo > discussion, so thanks for the feedback. > > With the issue of making a long review longer, I've revised my review > based on some of your comments, by adding notes - in most cases these > note that your text seems a paraphrase/clarification of the IPv6 node > requirments, and I tried to identify what was changed there, and > adopting thsi approach would I think improve the draft. I've also tried > to explain where I saw potential "node" rather than "host" changes. I > also was promted to look back at the WGLC and say some topics, which did > not yet seem resolved and adds notes regarding this. > > Best wishes, > > Gorry > > On 27/11/2024 23:57, Tom Herbert wrote: > > On Wed, Nov 27, 2024 at 1:47 AM Gorry Fairhurst via Datatracker > > <noreply@xxxxxxxx> wrote: > >> Reviewer: Gorry Fairhurst > >> Review result: Not Ready > >> > > Hi Gorry, > > > > Thanks for the review, Comments inline. > > > >> 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. > >> > > I disagree with that, especially the idea that this draft is ossifying > > IPv6. The whole purpose of this draft is to undo the ossification that > > has prevented deployment of IPv6 extension headers-- particularly, the > > tendency for many routers to just drop packets with Extension Headers > > or defer them to slow path processing is addressed by providing > > practical guidance. > > > >> 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. > >> > > Yes, also note that this works the other direction. QUIC, RFC9000, > > sets some limits on the length of Extension Headers in packets. > > > >> 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. > > As I pointed out in other responses, this draft is following the same > > trajectory as RFC8504 a BCP which obsoleted RFC6434 which was > > Informational and did use RFC2119 requirements language. If the > > consensus or ADs want to remove the language then of course we can, > > but personally I think that would water down the draft to the point it > > might be meaningless. > > > >> 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. > > Okay. > > > >> 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. > > Yes, but the draft is very clear that these are _minimum_ > > requirements. Currently, the standard says that the extension header > > length could be up to MTU, but de facto minimum support which is > > widely deployed is zero bytes. That minimum is the direct result of > > ossification which precludes the use of Extension Headers on the > > Internet. So, IMO, requiring a minimum level of support that is > > greater than zero but less than infinity is not exacerbating > > ossification, but is in fact addressing it. > > > >> ========= > >> > >> 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: > > The draft describes the behaviors that routers, hosts, and > > intermediate destinations follow wrt applying limits and what happens > > when limits are exceeded. The specific operation of that is outside > > the auspices of this draft and is covered elsewhere. > > > >> “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. > > I'm not sure what you think is short-sighted, is it the fact that some > > routers have ad hoc requirements to access the transport layer > > headers, or that we're trying to provide some reasonable guidance when > > they do that? I would agree with the former, but not the latter :-) > > > >> 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.” > > RFC9673 does not discuss Destination options, we cannot skip them in > > host processing. Also, while RFC9673 does allow nodes to skip some > > number of nodes, it provides no use guidance on how many options can > > be skipped without adversely affecting functionality and extensibility > > (that is what this draft does), > > > > Also about RFC9673, the draft states: > > > > "A Source MAY, based on local configuration, allow only one Hop-by-Hop > > option to be included in a packet, or it could allow more than one > > Hop-by-Hop option but limit their size to increase the likelihood of > > successful transfer across a network path." > > > > This text implies a default limit of one option, which could be > > inferred to be ossifying and limiting the evolution of IPv6 as much as > > this draft does. Restricting senders to only one option seems way too > > limiting (note, that I argued against this text in draft discussions > > and other requirements that could be inferred as setting limits). > > > > Also, "limiting their size to increase the likelihood of successful > > transfer across a network path" is useless guidance to me as an > > implementer-- do I need to limit it to 8 bytes, 64 bytes, 1024 > > bytes?.. we don't know. This is precisely why the header limits in > > this draft are so important, we can give intelligent guidance to a > > sender as to what they should reasonably expect to work, and guidance > > to receivers so that they can meet at least these minimum expectations > > (greater than zero). > > > >> 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. > > The MAY should be a "may". This draft does not update RFC8200, > > > >> ---. > >> 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. > > Note the prefaced condition that sets the applicability of the requirements. > > > >> ---. > >> 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. > > But, this draft _is_not_ requiring ordering or changing RFC8200. It is > > saying that _if_ a node chooses to apply restrictions or limits to > > protocol processing that are not mentioned or sanctioned by the > > Standard then this is the recommended way to do that to maintain > > interoperability and the spirit of Standard as much as possible. > > > >> 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. > > RFC8333 is already defined. Like any other ICMP errors, endpoints can > > take action on them or not per their discretion. > > > >> 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? > >> > > I don't believe there is a conflict here. The first requirement sets a > > general requirement for router behavior. The second requirement > > provides details on the behavior including what to do in the exception > > case for the SHOULD of the first requirement. > > > >> 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? > >> > > The padding options as well as other options are from RFC8504. This > > draft clarifies behavior, and extends the requirements to be > > applicable to non end hosts. > > > >> 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? > >> > > No. If a host is setting some limits then it would account for SR > > header. SRv6 would only be used in a limited domain so it's up to the > > operator to ensure compatibility (note that this draft doesn't change > > anything, use of the extension header is predicated on it being able > > to transit the path. > > > > The limits in this draft are really intended to be used when sending > > to hosts over a network for which nothing is known about their > > capabilities (.e.g the sending on the Internet). > > > >> 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? > > I think you're looking at this the wrong way. The goal isn't to > > "police" but to give the _existing_ "police" guidance to do a better > > job so we can break their ossification. The "police" are firewalls and > > routers that take upon themselves to not only "police" but to also > > define the rules without any openness. For instance, this draft > > addresses the problem that some routers that today drop all packets > > with any protocol other than TCP or UDP. If we give them better, > > practical guidance, maybe they can change these practices and hence > > move the needle on resolving ossification. > > > > Also, all of the limits in this draft are completely optional. We are > > not requiring anyone to set any limits (with the exception of the > > header chain limit in routers). Furthermore, the draft is also clear > > that any limits may be freely exceeded if the environment is well > > understood. So for protocols like IOAM, SRv6 that are only deployed in > > limited domains there is no conflict with limits. > > > >> - 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. > > IPsec and tunnel extensions are end-to-end. Routers only process HBH > > and nothing beyond. The only other consideration for routers is the > > header chain limit when a router needs to access the transport layer. > > Obviously, if IPsec is used the transport headers are unavailable, but > > that is not this draft's concern. All this draft is saying is that the > > mere presence of extension headers is not sufficient justification to > > drop a packet. Routers have to accept some non-zero length EHs when > > they are parsing over EH. > > > >> 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). > >> > > Will add references. > > > >> 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. > > The concern that this draft would ossify the IPv6 or limit its > > evolution seems to be a running theme in the comments, so I summarize > > several points in rebuttal. > > > > 1. Considering that we've had thirty years of experience with IPv6 and > > there is virtually no deployment of Extension Headers on the Internet, > > I'm not at all worried that _this_ is the draft that people will cite > > as inhibiting the evolution of IPv6 :-). In reality, the reason that > > EH hasn't yet succeeded isn't because it was too restricted, it's > > because the requirements are too open ended. Requiring a router to > > process every HBH option, or a host to process any number of EHs and > > all options in a packet are not realistic. We simply cannot build a > > usable Internet on the premise that nodes have unlimited resources to > > process an unlimited number of items. In lieu of IETF providing any > > useful guidance to address this, individual implementations have taken > > it upon themselves to define pragmatic limits. Unfortunately, that has > > resulted in implementations being all over the place and basically > > we're stuck with the Least Common Denominator which currently seems to > > be a limit of zero (hence, we can't use EH on the Internet). > > > > 2. This draft is about _all_ extension headers, not just HBH. > > Sometimes I get the feeling that people only see the problem of packet > > processing at routers (for instance, in the above comments RFC9673 is > > cited as addressing some issues, however that RFC is only concerned > > with HBH and says nothing about Destination Options or other EH). Once > > RFC8200 allowed routers to ignore HBH options that actually solves > > most of the router problem (except for the DPI and parsing buffer to > > access transport headers which is addressed by the router limits for > > EH length). While the problem may be solved for routers, for hosts > > it's a different story. Unlike a router, a host stack is required to > > process all EHs, all Destination Options, and IMO should have to > > process all HBH to address the security concerns cited above. While > > hosts might have more resources than a router to process headers, they > > also have a lot more requirements on what to process and hence have a > > greater exposure to DoS attacks involving EH. So limits on EH2 are > > paramount in a host stack, which leads to the third point... > > > > 3. Concerning the host side, most of the applicable limits are already > > implemented in Linux and have been deployed for a while (at least four > > years). So to a large extent, this draft isn't proposing host limits, > > it's documenting them! This includes padding limits and the number of > > HBH/DestOpts allowed. For instance, if a Linux server receives a > > packet with more than eight HBH options, it will drop the packet by > > default. I suppose a protocol purist might complain that we're > > violating RFC8200 and some time, probably in the distant future, > > someone might come up with a legitimate use case for nine options. But > > until that happens, such a complaint would fall on deaf ears. > > Protecting users and systems from an obvious DoS attack clearly trumps > > allowing unlimited extensibility that was not anywhere close to > > needing. > > > > Tom > > > >> ========= > >> 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=== > >> > >> > >> > >> > >> > > _______________________________________________ > > Tsv-art mailing list -- tsv-art@xxxxxxxx > > To unsubscribe send an email to tsv-art-leave@xxxxxxxx > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
