Reviewer: Gorry Fairhurst
Review result: Not Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Review for "Limits on Sending and Processing IPv6 Extension Headers"
NOTE: This updated review adds some notes with requested clarification. 

The document seeks to provide informational guidance on how to best configure
limits to IPv6 Extension Header processing. It  seems to provide two
contributions: - It seeks to ossify the IPv6 header structure, by suggesting to
deploy checks in routers and other nodes that drop packets when they do not
conform - It seeks to recommend values for the size and number of
extensions/options that may be expected to be included in an IPv6 packet.

The two contributions together seek to ease deployment of some types of
extension, by specifying minimum expectations.

On the one hand, if deployed this would ease section of appropriate sized
header chains by endpoints that would increase the chance of successful use
across an end-to-end path. One advantage of this approach is that it could
encourage greater deployment of in-network and stack support for extension
headers.

On the other hand, this would also result in discard of packets that include
extension headers that do not conform (in size or structure). This will prevent
other (new) types of extension. If published, it will likely have the impact of
ossifying IPv6 around these constraints, this will simplify the design, but
thought is needed around how to evolve to add different features in future.

The document discusses extension header use at end hosts, by routers, by middle
boxes, firewalls and devices performing operations such as ECMP.

Although an INT area specification, this has impact on whether an endpoint is
able to include destination and HBH options in packets that it sends, and
therefore it impacts has implications on the transport, which includes methods
such as racing, the use of tunnels/encapsulation by the end-to-end transport,
and methods such as OAM.  It also impacts the design of middle boxes.

In summary, I think the draft is not ready for publication. This document has
several major issues.

In all text below, the word "OLD" refers to the reviewed revision of the I-D.

General Review Comments:

1. Use of RFC 2119 Language
This draft contains RFC 2119 requirements language,
which maybe is not needed in an INFO document. I’d suggest using only lower
case terms, which would also remove the burden of proof that these are the
correct terms in each case.

Note: Some of the concerns emerge from normative text around previously published informational text. These specific concerns would be mitigated if the new document did not use RFC 2119 keywords, and instead using exact quotes of the original text (and referenced the RFC), rather than paraphrasing (please see the additional notes below). Some concerns relate to clarifications of a BCP, but don’t explicitly say which BCP section is being clarified in what way.

2. The I-D refers to itself as a specification in multiple places.
 For example:
OLD:
This specification includes limits on extension headers
NEW:
This document includes limits on extension headers

---
-
This reviewer suggests to use the word “document” throughout, because this is
to be published as Informational.

3. The appendix needs clearer scope to provide only the required background
information, not reiterate requirements. In the Annexe, OLD: This scheme thus
establishes a requirement that Internet devices must be capable of correctly
processing packets with up to sixty-four bytes of extension headers, and
subsequently it establishes a requirement that a host shouldn't send packets
with more than sixty- four bytes of extension headers unless it known that all
the nodes in the path can process packets with larger extension headers and a
larger IPv6 header chain. Note that this establishes a global minimum baseline
requirement across the Internet; within a limited domain higher limits could
freely be applied.

---
-

This language seems excessively strong for informational documentation.
- I would hope it establishes an expectation that Internet devices are able to
process packets. - It does not set requirements, but it could give very useful
guidance. 
- If published this guidance might be expected to become the norm,
which will ossify (significantly limit) the ability to change in future.



=========



Major issues:



1. This is an INT Area spec twith text that appears to speak about
  middleboxes, firewalls etc, but doesn’t really say so or discuss how they
  ought to operate. In particular the text motivates that routers ought to be
  able to interpret the transport headers:
“If a router needs to parse the upper layer protocol, for instance
to deduce the transport layer port numbers, it MUST be able to
correctly forward packets that contain an IPv6 header chain of 104
or fewer bytes, or equivalently, a router MUST be able to process
a packet with an aggregate length of extension headers less than
or equal to 64 bytes.

"

In the Appendix,

OLD:
A de facto requirement of many routers is that they need to process
transport layer headers in packets.
---


- I think this needs more clarification, and specifically ought to note the
 implications of performing deep packet inspection and mitigations there are to
 avoid this (see note on at least discussing the flow table as one remedy for
 ECMP).
- The growing use of VPN and other encryption makes this particularly
short-sighted. Although perhaps noting the intent of the flow label might help
in such an argument to mitigate the ossification around using transport
information in the network.

NOTE: A similar concern was noted by the WG Chairs while in WGLC, 
concerning discussion about the use of DPI.  


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.
---
-
NOTE: RFC9673 does not discuss Destination options, nor limits for host,
it only concerns the rules for the processing a HBH Extension Header.

- This seems to be no longer true after publication of RFC 9673, “IPv6
Hop-by-Hop Options Processing Procedures”, making HBH options skippable. RFC
9673 also sets configuration control that permits: “A configuration could
control whether normal processing skips any or all of the Hop-by-Hop options
carried in the Hop-by-Hop Options header.”


3. The following comments relate to changes that update the text of RFC8200,
 in terms of the structure of the header chain. This is a full standard, and
 there is no updates field to indicate there are changes to the specification
 of RF8200 (which might otherwise be a DOWN REF for an Informational I-D to
 makes new stronger rules for processing than currently  defined in a
 standard). When I reviewed the I-D, The document does not explain how these
 proposed changes were analysed or motivated.

NOTE: Some of the concerns here emerge from normative text around previously 
published informational text. These concerns would be mitigated if the new 
document did NOT use RFC 2119 keywords, and instead using exact quotes of 
the original text (and referenced the RFC), rather than paraphrasing 
(please see the additional notes below). In places it might be useful to 
directly cite and refer to BCP recommendations.

See below:



3.1 Would update RFC 8200 processing order of extension headers:

OLD:
A host or intermediate MAY enforce the recommended extension
eader ordering and number of occurrences of extension headers
described in Section 4.1 of [RFC8200].  Per the ordering
recommendations, each extension header can occur at most once in a
packet with the exception of Destination Options header which can
occur twice.
---.


and 

OLD:
If a host or intermediate node enforces extension header ordering
and a packet is received with extension headers out of order or
the number of occurrences of an extension header is greater than
one, or two for the Destination Options header, then the receiving
node SHOULD discard the packet and MAY send an ICMP Parameter
Problem message with code 8 (Too Many Extension Headers) [RFC8883]
to the packet's source address.

---.
and 

OLD:
Note that a host may enforce extension header ordering for all
extension headers in a packet, but an intermediate node may only
enforce ordering for extension headers up to and including the
Routing Header.

---

- RFC 8200, section 4.1, makes non-normative statements about the ordering of
extension headers: RFC 8200: When more than one extension header is used in the
same packet, it is recommended that those headers appear in the following
order:
...
---

- RFC 8200 the continues to say: “If and when other extension headers are
defined, their ordering constraints relative to the above listed headers must
be specified”

and RFC8200 states:
IPv6 nodes must accept and attempt to process extension headers in
any order and occurring any number of times in the same packet,
except for the Hop-by-Hop Options header, which is restricted to
appear immediately after an IPv6 header only.  Nonetheless, it is
strongly advised that sources of IPv6 packets adhere to the above
recommended order until and unless subsequent specifications revise
that recommendation.
---
- Therefore this I-D, if published, will change these recommendations by
suggesting a different set of rules for processing, or at least would change
the non-normative expectation of this full standard. - From a transport
perspective, enforcing extension header ordering for extension headers included
in a packet within an intermediate seems like it is a new obstacle for
incremental deployment.

3.2 This would update RFC 8200 with new stronger rules for the number of
times an extension header can appear, restricting what is currently allowed.
RFC 8200: Each extension header should occur at most once, except for the
Destination Options header, which should occur at most twice (once before a
Routing header and once before the upper-layer header). ---
- - Is there
evidence (I did not see a reference) that says whether this will cause more
paths to drop packets, or whether this is expected to encourage more paths. Is
there any measurement data? - From a transport perspective: Enforcing extension
header ordering for extension headers included in a packet within an
intermediate seems like it is a potential obstacle for incremental deployment.

Note: Citing or quoting RFC 8504 would help clarify this.



3.3 This would change the method in RFC 9673, which motivates skipping
  unknown or un-configured HBH options.

OLD
:
It is NOT RECOMMENDED that the router discards the
packet because the limit is exceeded, however if it does then the
router MAY send an ICMP Parameter Problem message
---
and 
OLD:
If a packet is received
and the number of Destination or Hop-by-Hop options exceeds the
limit, then the receiving node SHOULD discard the packet and MAY
send an ICMP Parameter Problem message with code 9 (Too Many
Options in Extension Header) [RFC8883] to the packet's source
address.

---
- It seems to change the expectation in RFC 9673 by specifying different rules
when more HBH options within an EH than expected (i.e., it says “not
recommended” rather than RECOMMENDED to skip).  This change appears to create
more opportunities for path failure (discard of packets by a path), was this
change intended?



3.4 If published, this would update RFC 8200 with new stronger rules for
  generating ICMPv6 messages.

- In various places there is text about optionally generating ICMPv6 messages,
 whereas RFC8200 seems to indicate nodes should generate ICMP messages when
 packets are discarded. This could be OK, but is there a reference to support
 this rule? OLD:
It is NOT RECOMMENDED that the router discards the
packet because the limit is exceeded, however if it does then the
router MAY send an ICMP Parameter Problem message
---

- There was a general principle that packet discard should result in ICMPv6
 messages indicating the problem encountered, which seems to be what RFC8200
 states. It is not the case that endpoints expect to see these messages,
 none-the-less this isn’t a PS and therefore this should likely point to the
 RFC that describes when ICMPv6 is used.


4. The following new rule partly seems to contradict another new rule in this
 I-D:
OLD:
If a limit is exceeded, routers SHOULD still
forward the packet and SHOULD NOT drop packets because a limit is
exceeded.

---


The conflict is with,
OLD:
A router MAY disallow consecutive padding options, either PAD1 or
PADN, to be present in the Hop-by-Hop Options header.  If a packet
is received with consecutive padding options that are disallowed
by the router, then the router SHOULD stop processing the Hop-by-
Hop Option header and ignore any Hop-by-Hop options beyond the
limit.  It is NOT RECOMMENDED that the router discards the packet
because the limit is exceeded, however if it does then the router
MAY send an ICMP Parameter Problem message with code 7 (Too Many
Options in Extension Header) [RFC8883] to the packet's source
address.
---

- Could this rule be changed to “Routers ought to forward packet when  the
limit is exceeded”

- In which case, ought they not also to skip the remaining options and process
 the packet, which might involve processing additional extension headers?

NOTE A similar concern was noted by the WG Chairs while in WGLC:   
"We don’t think this document should be making protocols changes, 
it should be focused on setting limits."

NOTE: “NOT RECOMMENDED that the router discards the packet…” 
perhaps ought to be “RECOMMENDED that the router does not discard the packet…”

NOTE: Normative node rules for handling padding are stated in RFC 8504 section 5.3,
this needs to be cited here. It would be helpful to motivate choices; 
or to explicitly cite any change to RFC 8504.


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?

NOTE: Current normative node rules for handling padding are stated in 
RFC 8504 section 5.3, this should be cited or quoted, and any refinement 
compared to that text.



6. Does that mean a host becomes restricted in how it can use destination
 options end-to-end when it includes  (for example SRV) extension header?


OLD:

A source host SHOULD NOT send a packet with an IPv6 header chain
larger than 104 bytes unless it has explicit knowledge that all
possible routers, intermediate nodes, and the destination host in
the path are able to process a larger IPv6 header chain.  If a
packet contains an IPsec header then this limit only applies
through the end of the IPsec header (the IPsec header obfuscates
following headers so that they are unreadable by nodes in the
path).  This requirement is equivalently stated as a host SHOULD
NOT send a packet with more than 64 bytes of aggregate extension
headers.
---


- Does this have implications at the transport layer on what destination and
 HBH options can be sent?  The problem I fail to understand is how the
 processing on the path impacts the choices available at the endpoints,
 especially if the set of EH are not delivered to the final transport endpoint.
 - Restrictions arising from a need for visibility of the transport header seem
 a significant change to the IPv6 specification. For a packet that includes a
 routing header or other extension header used on a part of the path, it then
 appears to limit what options/size the host can use end-to-end across the
 transport connection. Similarly, the document does not discuss the addition of
 extension headers for purposes such as OAM, which I also assume  that an
 endpoint needs to discover before it adds extensions - since network paths
 might then “police” the overall header chain?
- How do these restrictions apply to the processing of packets that include an
IPSEC header, tunnel extension, or something similar that relate to all or a
part of the path being used? How does the sending endpoint discover this limit
that appears on-path? It seems the only way to evolve and use new headers is
for the transport to use a method that would deliberately hide the extension
headers from the routers on the path (as in IPsec currently), which appears to
prevent access on the path to the transport header (which was one of the
motives of this proposal). Please calrify how this evolution will play out.

7. I have concerns about the completeness of the analysis of the currently
deployed support (see Appendix). This could be remedied by citing and comparing
a range of sources. It is generally unwise to base decisions on presentations,
and I would encourage a wider set of sources (single point measurements are
prone to bias from using a specific vantage point from which to measure - which
is the topic of [Cus23a]).  Please use archived journal publications (where the
scientific rigour/review helps support the claims and the methodology is clear).

NOTE A similar concern was noted by the WG Chairs while in WGLC.


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.

Note: The discard of non-conformant packets by nodes is likely to result in 
restricting any future attempt to raise the minimum values stated in this I-D. 
Previously discard of packets seems scoped to permitted by hosts (endpoints).

Note: Section 5.2 of RFC8504 defines the current normative procedure for 
defining new Extension Headers and RFC 7075 specifies forwarding for packets 
that include unrecognised extension headers and specifically a requirement 
not to drop packets solely due to included extension headers.


=========

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