On Wed, Feb 19, 2025, 3:29 AM Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
On 18/02/2025 18:47, Tom Herbert wrote:
> On Tue, Feb 18, 2025 at 9:31 AM Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
>> On 18/02/2025 16:38, Tom Herbert wrote:
>>
>> Hi Gorry,
>>
>> Thanks for your comments. Responses in line.
>>
>> On Tue, Feb 18, 2025 at 3:26 AM Gorry Fairhurst via Datatracker
>> <noreply@xxxxxxxx> wrote:
>>
>> Reviewer: Gorry Fairhurst
>> Review result: Ready with Issues
>>
>> 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. My previous archived TSV-ART review
>> highlighted several concerns. This is a new review following substantive
>> changes by the editor (thanks Tom) that has resolved many of the comments in
>> that last review.
>>
>> Although this is a proposed 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
>>
>> Such limitations already exist on the Internet. The data on drop rates
>> of packets with extension headers confirms that. Right now, there is
>> no guidance on what sending hosts need to do to avoid drops (other
>> than not using EH). This document provides some useful guidance.
>>
>> 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, hopefully the outcome is fewer packet drops!
>>
>> Yes, that was a summary of why I thought this document was relevent.
>>
>> The support for two Destination Options Extension Headers in IPv6
>> is also potentially confusing for a reader - only one of these EH is concerned
>> with end-to-end transport!
>>
>> I assume you mean Destination Options before and after the Routing
>> Header? That's from RFC8200 to allow two Destination Options in the
>> same packet with different semantics. I'm not sure what you mean by
>> "only one of these EH is concerned with end-to-end transport!"
>>
>> Yes. From the IETF transport perspective the two DO EH have different functions and different needs, one relates to what you have named "Intermediate nodes" and one to end-to-end aka endpoint transport.
>>
>> My comments in this review concern the intermediate node, and what needs to happen when there is an intermediate node on the path between the sending and recieving transport endpoint.
>>
>> Major:
>> ===
>> 1. Extensibility language
>> In section 3:
>> /A source host SHOULD follow the recommendations in Section 4.1 of
>> [RFC8200] for extension header ordering and number of occurrences
>> of extension headers./
>> - This is the place where I noted in my earlier review that the document seeks
>> to make lower case descriptive recommendations into RFC2119 requirements. This
>> type of update is unusual, although within the context of this draft I can
>> understand the intent and the desirability of this approach. - If this approved
>> - I think this needs to be called out to the iESG - and the wording here likely
>> needs to be strengthened to explained that the are now recommended, and that
>> the rationale for why the SHOULD can be changed needs to be explained- I was
>> assuming this is to permit future experimentation, standardisation and
>> deployment of new extension headers? - I also think a reference to RFC8504 is
>> needed here to explain how to define a new extension header.
>>
>> I will change that to "should"
>>
>> ===
>> 2. Discard by an Intermediate Node
>> As a transport person, the end host recommendation is fine - if a packet
>> reaches the end and has a problem, i expect it to fail to be delivered. This is
>> not a show-stopper, but it is a concern.
>>
>> I’m less familiar with intermediate nodes on-path processing the routing header
>> and how they impact my end to end view of the path. In many ways I welcome
>> making this more explicit. However, it also raises a concern when the routing
>> functions possibly lead to unexpected loss, making path more difficult for the
>> transport to understand.
>>
>> That seems to be a general concern not specific to this draft: when
>> routers or intermediate nodes discard packets the end hosts will not
>> understand what's happening. The goal of this draft is to reduce such
>> discards.
>>
>> This is a special case where an ICMPv6 message would
>> be really helpful to trace and debug operation (albeit with the usual caveat
>> that the ICMPv6 message may not reach the sender). I think the appropriate
>> action when a limit is reached is an INT AREA question, so I’ll flag this as a
>> major issue.
>>
>> There are recommendations for sending ICMPv6 messages when nodes drop
>> packets. E.g. "If the receiving node discards the packet because the
>> limit is exceeded, then it MAY send an ICMP Parameter Problem message"
>>
>> There are several places where this applies for intermediate nodes, in Section
>> 4.
>>
>> Yes, that's calling this out to my AD so he may check more if he/she needs to. Imposing limits to devices on the path could add new challenges to understanding some paths - but setting sensible limits could help in the general case.
>>
>> ===
>> 3. Rules relating to HBH Options.
>> Section 4:
>> /If a packet is received
>> and the number of Hop-by-Hop options exceeds the limit, then the
>> receiving node MAY either: 1) discard the packet, or 2) stop
>> processing the Hop-by-Hop Options header and process the rest of
>> the packet normally./
>> - I think (2) and the following MUST are incorrect. This is a special case of
>> the forwarding extensibility, and as such we need a clear guidance, as defined
>> in RFC 9673. An end host cannot know the set of router configurations along its
>> path, and hence this needs to not result in discard. The specific requirement
>> added in that RFC was: / If a router is unable to process a specific Hop-by-Hop
>> option (or is
>> not configured to do so), it SHOULD behave in the same way specified
>> for an unrecognized Option Type when the action bits are set to "00",
>> and it SHOULD skip the remaining options using the "Hdr Ext Len"
>> field in the Hop-by-Hop Options header. /
>> - I was hoping to see text that was more like this:
>> /If a packet is received
>> and the number of Hop-by-Hop options exceeds the limit, then the
>> receiving stops
>> processing the Hop-by-Hop Options header and process the rest of
>> the packet normally, see Section 5.2 of [RFC9673]./
>>
>> The requirements you are quoting only apply to destination nodes
>> (hosts and intermediate nodes in a routing header). Section 5
>> describes the router requirements which match what you are proposing.
>>
>> The thing I am not hearing is what needs to happen when there is an intermediate node, that forms a part of the path between the transport endpoints.
> Hi Gorry,
>
> I assume by "transport endpoints" you mean hosts or end hosts (and not
> L4 end points). The requirements for intermediate nodes are
> articulated in Section 4, like "A host or intermediate node MAY set a
> limit on the maximum number of non-padding options allowed in a
> Destination Options header or Hop-by-Hop Options header.". Also note,
> that a node doesn't know that Destination Options are before the
> Routing Header until after the Destination Options have been
> processed, so there's no need to distinguish processing DO before a
> routing header or processing DO when there's no Routing Header.
Yes, I read that. I mean the thing that would terminate a TCP or QUIC
connection for example. To me all that is between is just part of the
path the transport needs to figure out.
Hi Gorry,
I'll note that QUIC already sets some limits on EH. From RFC9000:
Note: This requirement to support a UDP payload of 1200 bytes limits the space available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if the path only supports the IPv6 minimum MTU of 1280 bytes. This affects Initial packets and path validation.
Tom
>> ===
>> 4. Limits to HBH Size in Section 4:
>> / If a packet is received
>> and the length of the Hop-by-Hop Options header exceeds the limit,
>> then the receiving node MAY either: 1) discard the packet, 2) skip
>> processing of Hop-by-Hop Options header and process the rest of
>> the packet normally, or 3) process the options up to the one that
>> causes the limit to be exceeded and then stop processing of the
>> Hop-by-Hop Options header and process the rest of the packet
>> normally. /
>> - There are three suggested options provided in the I-D for a length limit when
>> a packet includes a HBH EH. Para 2 of Section 5.2 in RFC 9673 recommends
>> approach 3. - I think that RFC2119 recommendation ought to be stated in this
>> I-D.
>>
>> Again, note that this text only applies to hosts and intermediate
>> routers. Option #1 is what is currently supported in LInux stack.
>> Either all Hop-by-Hop and Destinations options must be processed or
>> the packet is dropped. This is done to maintain a strong security
>> posture, that is hosts should not blindly accept packets without
>> inspection. Option #2 allows a node to avoid processing partial
>> Hop-by-Hop options and this degenerates to skipping HBH options
>> entirely which is allowed by RFC8200. Option #3 follows RFC9637. Also
>> note the inherent ambiguity of RFC9673 in trying to avoid "adversely
>> impacts the aggregate forwarding rate"-- that is not something that
>> can be normatively defined. However, the lengths of headers are more
>> concrete because of typical parsing buffer design.
>>
>> I understand the point for a end host.
>>
>> The comments relates only to limits at Intermediate nodes.
>>
>> RFC9672 is also postured to allow the HBH extension header to be incrementally deployed and used. I don't see that (2) helps, or should be specified as an alternative to RFC9672.
> #2 is allowed by RFC8200 since the whole HBH Options header may be
> skipped. It's easy to implement since node just needs to look at the
> extension header length.
Yes.
>
> Also, note that RFC9672 only discusses HBH and not Destination
> Options.
Yes.
> For Destination Options, there is no provision that either
> hosts or intermediate nodes can skip processing any of the Destination
> Options. So only Option #1 is really the only viable choice for
> Destination Options, either a node processes all Destination Options
> it's supposed to or it needs to drop the packet.
Yes, that is why I asked to consider if the Intermediate node advice
would be different for a DO EH and for a HBH EH.
>> ===
>> 5. Which of the two Destination Options EH is being discussed in Section 4
>> relating to Intermediate nodes? IPv6 [RFC8200] clearly identifies two usages of
>> the DO. I think in the context of this I-D, when a DO is checked by an
>> intermediate node, it refers only to “or options to be processed by the first
>> destination that
>> appears in the IPv6 Destination Address field plus
>> subsequent destinations listed in the Routing header.” As in note
>> 1 of Section 4.1 of RFC8200.
>> - This needs to be clarified. I also think this the citation to “: note 1 of
>> Section 4.1 of RFC8200” is necessary and also a later citation when speaking
>> of host limits to “options to be processed only by the final destination of
>> the packet (see note 3 of Section 4.1 of RFC8200)”.
>>
>> Intermediate nodes on process Destination Options before the routing
>> header, and hosts process both Destination Options. The requirements
>> apply in those applicable cases. Also, note that implementations don't
>> need to distinguish between Destination Options before or after the
>> Routing Header-- all instances of Destination Options in a packet can
>> be processed the same way.
>>
>> Before I read this document, I did not think further about this - but since this introduces the concept of an Intermediate node, it leads me at least to question if this really is the case. I'll let others decide.
> Routing Headers do make things a bit interesting since they have
> properties of both hosts and routers. For instance, I think for
> processing HBH Options at an intermediate node it's safer to ignore
> HBH options than it would be for the end host. In any case, I do think
> they need to be drawn out (there was discussion in WG about this).
Indeed - if that suggestion came from the WG, it would be helpful to
note it.
To me though I at least encourage you to say the considerations may be
different, so that a future reader undeerstands.
> Thanks,
> Tom
Thanks for asking for clarification. I think we arrived at an
understanding of my comments and I'll leave others to reflect and decide
if there is anything else to add on this topic.
Very best wishes,
Gorry
>
>> ===
>>
>> I have the following editorial comments on the latest revision:
>> ===
>> 1. Editorial:
>> In section 2 there is a helpful list of limits. This does not include an item
>> stating the: * ordering and type of extension header. - although this time is
>> later presented as a limit that could be checked.
>> ===
>> 2. Editorial:
>> /Excessive Hop-by-Hop options in
>> a packet has also been raised as a security concern [RFC4942]./
>> A packet that includes an excessive number or size of Hop-by-Hop options in
>> a packet has also been raised as a security concern [RFC4942]./
>> - This is a suggestion to improve reading.
>> ===
>> 3. Editorial:
>> /The limits in this document are optional./
>> - I understand this, but it seems slightly terse and possibly a confusing
>> statement, I’d recommend it could be refined or removed.
>> ===
>> 4. UK English. This sentence reads OK in US English, but is difficult to
>> correctly read for someone familiar with UK English /If a
>> packet contains an IPsec header then this limit only applies
>> through the end of the IPsec header /
>> - Please could the word /through/ be replaced by /up to and including/ or
>> something else?.
>> ====
>> 5. Two or one Llimits to HBH and DO Size in Section 4:
>> / * A host or intermediate node MAY set a limit on the length of a
>> Destination Options header or a Hop-by-Hop Options header. If
>> this limit is supported then the limit SHOULD be configurable and
>> the limit SHOULD be greater than or equal to 64 bytes. /
>> - Is that a separate limit for each size, or a combined size of 64 bytes, this
>> is not clear.
>> ===
>> 6. The rules relating to HBH and DO at intermediate nodes do not seem to be the
>> same. I think it would be easier on the reader, if the limit checks in section
>> 4 text relating to HBH Option & DO were now divided into two paragraphs of
>> text, one about HBH and one about DO.
>>
>>
>>
>> Thanks Tom, for getting back quickly, I think my comments are understood, and I'll leave those reading the reviews to see if they wish to follow-up on any of these topics.
>>
>> Best wishes,
>>
>> Gorry
> _______________________________________________
> 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
