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.
===
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
