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

[Jen Linkova <[e-mail]>]

Adding the WG this time for real..

On Wed, Nov 8, 2023 at 1:01 AM 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.
>
> 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.
>
> 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.
>
> In the document, having separate text about limits for routers and
> routers processing routing headers adds complexity.  Is it possible to
> consolidate these limits?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 2.1 Types of nodes
>
> Given the addition of Section 1.2 Terminology, is this section still
> needed?  Seems mostly redundant.
>
> 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.
>
> 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.
>
>
> 2.2.4 Limits on number of options
>
> Please add reference for “P4”, it’s not well known.
>
>
> 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?
> 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".
>
>
>
> "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?
>
> "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.
>
> Note, “intermediate node” is still in this text in a few other places
> and in some section headers.  Please fix them.
>
> "However, the use of the Authentication header without encryption is
> likely rare on the Internet.”
>
> Do you have any data to support this statement?
>
> This document, should not have the side effect of making the
> Authentication header impossible to use.
>
>
> 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 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.
>
> 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.
>
> 3.2 Host requirements
>
> Why say “Source host”  or “destination host” vs. just “host”.   The
> text is clear about describing sending or receiving.
>
> 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"?
>
> 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?
>
> 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.
>
>
> 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.
>
> 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?



-- 
Cheers, Jen Linkova