Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

[Fernando Gont <[e-mail]>]

Hello, Tom,

On Thu, 2021-06-10 at 22:48 -0700, Tom Herbert wrote:
> Aside from a bunch of other evil details:
> > 
> > WHat if, say, you employ this solution at, say, connection-
> > establishment time, find that EHs actually "work" towards your
> > destination, but them, sometime later, the path to your
> > destinationchanges, and you find out that EHs no longer work?
> > 
> 
> That scenario isn't all that much different than rerouting causing a
> flow to not hit the same stateful middlebox, or a NAT state times
> out,
> or any other instances of something in the network rendering a
> connection too no longer viable. In all these cases, the application
> just restarts the failed connection.

There are multiple differences here:

* Packet drops can happen all over the place, whreas e.g. transit ASes
won't usually do the kind of stateful operations you're referring to.

* Issues arising from EHs can be avoided, while the other ones cannot.



> >      Abort the transaction/connections?
> >      "Migrate" from EH-based mechansim to the fall back mechanism?
> >      Anything else?
> > 
> > What about the impact on e.g. RTT for connection-establishment?
> > What
> > about the complexity of the mechanism? How many bugs/vulns before
> > every
> > implementation gets it right?
> > 
> All the more reason we need to establish some guidelines as to what
> the host can send in terms of extension headers and correspondingly
> what intermediate nodes should support.

The problem is not establishing guidelines, but rather establishing
guidelines that folks find that there's a compelling reason to follow.



>  Since RFC8200 allows
> intermediate nodes to skip over HBH options, then the pertinent limit
> would seem to be how long the IPv6 header chain is (solely for the
> benefit of those routers that require parsing of the transport
> header). I believe at least 128 byte parsing buffers are well
> supported by vendors, and assuming 16 bytes for L2, and first 8 bytes
> of transport header might need to be accessed by intermediate nodes,
> then that implies a minimum default of 104 bytes and subtracting
> forty
> bytes for IPv6 header gives nice round number of sixty four bytes for
> extension headers. Hence, I suggest the requirements should be:
> routers MUST forward IPv6 packets with sixty-four bytes or less of
> extension headers, and correspondingly hosts MUST NOT send packets
> with more than sixty-four bytes of extension headers unless they have
> knowledge that the path supports a greater number.

Note: the "64 bytes" should accommodate the upper layer header. -- at
the very least, that part with the port numbers.


Thanks,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531