[IPv6]Re: [Tsv-art] Re: Tsvart last call review of draft-ietf-6man-eh-limits-16

[Gorry Fairhurst <[e-mail]>]

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
> <[e-mail]> 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
>> [e-mail] 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]