[IPv6] Fwd: Updated review of draft-ietf-6man-eh-limits-08

[Tom Herbert <[e-mail]>]

Forwarding to 6man list


---------- Forwarded message ---------
From: Tom Herbert <[e-mail]>
Date: Wed, Nov 8, 2023 at 1:22 PM
Subject: Re: Updated review of draft-ietf-6man-eh-limits-08
To: Jen Linkova <[e-mail]>
Cc: 6man Chairs <[e-mail]>


Hi,

Thanks for the review. Comments in line.

On Tue, Nov 7, 2023 at 4:01 PM Jen Linkova <[e-mail]> wrote:
>
> Tom,
>
> The document is significantly improved.   Thanks for resolving most of
> the issues we raised.
>
> We have following high level comments:
>
> Overall, we think the document is long and may be hard for
> implementations to understand.  Finding way to shorten and simplify.
> Having a table of the limits would make it easier to understand and
> implement.

Okay, will add a table.

>
> We think that terms like limited domains will make this challenging to
> get through the IESG given it’s lack of clear IETF definition.  Note,
> we are not suggesting that it be defined here, better to remove it.
> The text about explicit knowledge should cover this.

Note that limited domain is not referred to in any of the normative
requirements specified in the draft. We could reference RFC8799 if
that would help, or remove all instances of the term. Which would be
better?

>
> Similar concern about the use of DPI.   That is a broader concept that
> just at IPv6 header chains.   We don’t think it is necessary to be
> included here.

Similarly, DPI is not used in any normative requirements. Will remove the term.

>
> In the document, having separate text about limits for routers and
> routers processing routing headers adds complexity.  Is it possible to
> consolidate these limits?

I will take a look, note that there are differences in processing
since router processing routing headers has some different
requirements (around processing Destination Options)

>
> We think the document could simplified if it only focused on length of
> EHs (~64 bytes) and not get into the number of things like padding
> options, or making distinctions between options and padding options.
> We think this would meet the overall goals, but be simplifier to
> understand.

RFC8504 already provides host limits for padding and makes that
distinction, and RFC8883 also makes a distinction with regards to ICMP
errors when extension header limits. IMO, it's better to be complete
even if it takes some more words.

>
> We also think that there doesn’t need to be limits on destination EHs
> for destination hosts.  Note, we do think there should be limits on
> what hosts send that match the limits that routers have.

Why do you think we don't need those limits? Note that RFC8504
specifies such limits and so they are being reiterated here. From
RFC8504: "A host MAY impose a limit on the maximum length of
Destination Options or Hop-by-Hop Options extension headers"

>
> Specific comments on draft-ietf-6man-eh-limits-08 below.
>
> Bob, Jen, Ole
>
>
>
> 1.2 Terminology
>
> Why is NAT mentioned in the terminology section?   We don’t see any
> other mention in the document, we think should be removed.

Okay.

>
> The terminology for terms defined in RFC8200 should be exact quotes,
> not summarized.
>
> Header Chain vs. IPv6 Header Chain?   Why the distinction?   We think
> “Header Chain” is sufficient.  Also, we note in Section 2.2.6 some of
> this is described, but we think the limits defined in this draft
> should only apply to the outer most IPv6 headers.

I think you're referring to the text: "In addition to limits on the
length of the IP header chain, it is conceivable that there could be a
limit on the length of the whole header chain in a packet.  The whole
header chain would comprise the IPv6 header chain as well as any
headers that are part of network encapsulation that precedes the
innermost transport layer."

This is a limit that could be applied to packets, it is related to EH
limits, but not in itself an extension header limit. There should not
be any normative requirements for it, however IMO it's pertinent to
mention the interaction of this limit with the other extension limits.
This is explicit in RFC8883 where an ICMP Destination Unreachable
message is defined for a router to send when the aggregate header
chain exceeds the limit, and we need to specify the precedence for
reporting an ICMP error when multiple limits are exceeded.


>
> 2.1 Types of nodes
>
> Given the addition of Section 1.2 Terminology, is this section still
> needed?  Seems mostly redundant.

Okay, will remove.

>
> Is there a way to simplify the document by not treating “routing
> processing routing headers” as a separate case? Also, the definition
> of "router processing the RH" and "router not processing the RH" look
> rather complicated and confusing.

Will try to consolidate.

>
> 2.2 Types of Limits
>
> Are Sections 2.2.1, 2.2.2, 2.2.3 still needed?  They don’t appear to
> say very much.

Okay, will remove

>
>
> 2.2.4 Limits on number of options
>
> Please add reference for “P4”, it’s not well known.

Okay

>
>
> 2.2.6.  Limit on IPv6 header chain length
>
> The text says: "In addition to limits on the length of the IP header
> chain, it is
>    conceivable that there could be a limit on the length of the whole
>    header chain in a packet.  The whole header chain would comprise the
>    IPv6 header chain as well as any headers that are part of network
>    encapsulation that precedes the innermost transport layer.  The
>    definition of such a limit is out of scope for this specification,"
>
> As per the Terminology section, "the whole  header chain" == "the IP
> header chain" + the IPv6
> header, so there is always just 40 bytes difference between them. So
> how can the router have different limits for those two header chains?

No, the IPv6 header chain includes RFC8200 defined extension headers.

> Also,  "the innermost" part is confusing. Does that mean that in case
> of encapsulation, the header chain includes all encapsulation
> overhead? It seems to be inconsistent with the Terminology section,
> which doesn't mention "the innermost".

Will rectify the terminology. The aggregate header chain could include
encapsulation headers.

>
>
>
> "The Encryption header may be used on the Internet,”
>
> We had thought that it was widely used for VPNs.
>
> Also, that sentence says that encryption obfuscates the encapsulated
> transport headers - so does it mean that the header chain covers the
> whole packet? In that case wouldn't any ESP packet exceed the limits
> defined in the document?

EH limits can only apply to headers that are in plain text. For
instance, if the ESP may contribute to the limit for the number of
extension headers in a packet. ESP effectively terminates the header
chain in such a way that the transport layer is not visible. If a
router needs to process the transport layer, for instance it's doing
port filtering, then the effect might be the same if that aggregate
header chain is too long-- in either case if the router can't access
the transport ports it might drop the packet per its configured
policy.

>
> "Fragmentation may be used in the Internet, however only the first
> fragment of a fragmented packet contains transport layer headers that
> could be read by an Intermediate node.”
>
> Suggest something like:
>
> When Fragmentation is used in the Internet, the first fragment is
> required by RFC8200 to contain all of the headers up to and including
> the transport header, these headers can be read by a router.

Okay

>
> Note, “intermediate node” is still in this text in a few other places
> and in some section headers.  Please fix them.

Ack, thought I eliminated all of those!

>
> "However, the use of the Authentication header without encryption is
> likely rare on the Internet.”
>
> Do you have any data to support this statement?

No, will remove

>
> This document, should not have the side effect of making the
> Authentication header impossible to use.

Nothing in the draft makes anything impossible to use, all limits are optional.

>
>
> 2.3 Actions when limits are exceeded
>
> General comment:  I don’t think the doc need to say “router not
> processing routing headers”, just saying “router” should be
> sufficient.

In cases where there's no need to make a distinction

>
> In the paragraph starting with “For routers not processing routing
> headers…”, there is no relation between processing Hop-by-Hop options
> and processing routing headers.   We found this confusing.
>
> “[RFC8200] and
> [I-D.ietf-6man-hbh-processing] allow that routers may not process the
> Hop-by-Hop Options headers, therefore a router processing routing
> headers may ignore all of the Hop-by-Hop options in a packet. This
> specification expands on that requirement to allow an to process some
> arbitrary subset of consecutive Hop-by-Hop options in the TLV list
> and to ignore the following ones.”
>
> We don’t think this document should be making protocols changes, it
> should be focused on setting limits.  Please remove.

That would be a problem. I'll show this by example. Suppose a router
implements a limit of eight Hop-by-Hop Options. When a packet is
received with 20 HBH Options which options are processed. The choices
seem to process none of the options or process 9 options and ignore
the rest. If the decision is to not process any of the options when
the limit is exceeded then the problem is that we can't know the limit
is exceeded without scanning the list of TLVs.  So basically, we have
to do all the work parsing TLVs and if we defer processing of the
options before we know if the limit is exceeded then we may have to
parse TLVs a second time! I don't see a feasible means to support that
in a high performance datapath.

The "expands on this requirement" wording is a vestige from earlier
drafts that would have updated RFC8200. I think the wording can be
removed and the procedures remain the same on the basis that HBH
Options can be ignored if they are unknown options-- that is treat the
options past the limit as being unknown options that would not have
been processed would be consistent with the intent of RFC8200.

>
> In the last paragraph in this section, we didn’t understand what is
> trying to be said.   The comparison with hosts is not correct (hosts
> would process all the rest of the packet).   This needs more work to
> clarify.
>
> 2.5 Design Philosophy
>
> We continue to think this document would be clearer with more focus on
> routers, and less on hosts.  It’s not clear there needs to be the same
> kind of receiving limits in hosts.   As noted in the draft “hosts
> typically have more processing capabilities”.   Note, it does make
> sense to specify the host sending requirments to match the router
> limits.

Yes, hosts have more processing capabilities, however they are far
from infinite. A while back, I ran the experiment of sending >1000
unknown Destination Options to a Linux system and that was sufficient
to peg CPU utilization at 100%. That is a potential DOS attack and
something we can address with limits described in this draft. Also,
the processing requirements in hosts are very different. For instance,
there is no provision here or anywhere else that a host can ignore
Destination Options-- so if a host cannot ignore options, so if a
limit is exceeded the host has no choice but to drop.

>
> 3.2 Host requirements
>
> Why say “Source host”  or “destination host” vs. just “host”.   The
> text is clear about describing sending or receiving.

Okay

>
> The two section headers titles are inconsistent in style:
>
> 3.2.1. Source host requirements
> 3.2.2. Receiving extension headers by destination hosts
>
> General comments for these sections.
>
> Most but not all items includes “unless it has explicit knowledge”.
> The text could be simplified if that was stated in the beginning of
> the section instead of in each item. Also, is it intentional that not
> all items have that text about explicit knowledge"?

I suppose, but personIy as a developer I like the idea of specifying
it with each normative requirement to avoid any ambiguity even if it
is a little more verbose.

>
> The document sets limits in both numbers of options and total length.
>  We had thought the focus was driven by how may bytes a router could
> process, do we need the number of options?

IMO, it's the other way around, the more critical parameters are the
number of options because that dictates the processing cost. There are
significant cost processing options especially when they're TLVs
(variable length, combinatorial ordering). For instance, a router may
be able to handle an arbitrary number of bytes of extension headers
but might be motivated to set a limit on the number of options in
order to avoid DOS attack (e.g. sender sends a whole bunch of tiny
unknown options in packets). Note that sending big unknown options
isn't nearly as effective for a DOS attack.


> 3.2.2. Receiving extension headers by destination hosts
>
> We are still not convinced that limits need to be specified for
> destination hosts.   Basically, if the packet got there, the host
> should process it.  It is very different from the limits that routers
> have forwarding packets.

I disagree. IMO, it's a common misnomer to think that hosts aren't
susceptible to DOS attacks in this area (I know they are from
experience :-) ). Also, see preivous comments and I'll again note that
RFC8504 already establishes some of these limits for hosts so there is
precedent.

>
>
> Section 3.3 Router requirements
>
> In the first paragraph it says “The limits described in this section
> should all be configurable and therea are default values specified if
> the limits are set”.   But then in the following text the does appear
> to specify specific limits (for example, 104 bytes).  Please clarify
> this.
>
> Some of the items in this list here are not about “limits”.   For example:
>
>  *  Per [RFC8200] a router MAY be configured not to process Hop-by-Hop
>     Options headers.  If a router is configured as such and a packet
>     with a Hop-by-Hop Options header is received, the extension header
>     MUST be skipped and the packet MUST otherwise be properly
>     processed and forwarded.
>
> *   If a router encounters an unknown Hop-by-Hop option and the two
>     high order bits are not 00 then the router SHOULD immediately stop
>     processing the Hop-by-Hop Options header and ignore any Hop-by-Hop
>     options beyond the unknown option……..
>
> We think this is out of scope for this draft and should be removed.

Okay

>
> Section 3.4 Intermediate destination requirements
>
> Change section title to Router Processing Routing Headers
>
> However, this seems like a lot of complexity and we am not sure why
> processing EHs before routing headers need to be different.  Don’t all
> routers need to be able to process routing headers?

No, I don't believe that's a requirement. For instance, not all
routers are capable of processing segment routing headers.