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

[Tom Herbert <[e-mail]>]

On Thu, Jun 10, 2021 at 10:21 PM Fernando Gont
<[e-mail]> wrote:
>
> Hi, Pascal,
>
> On Fri, 2021-06-11 at 05:00 +0000, Pascal Thubert (pthubert) wrote:
> > This might need a solution be similar to the MTU problem; e.g.,
> > during PMTUD a node might add the HbH Options that it needs to check
> > that the options make it through…
>
> 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.

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

Tom

> Truth #3 of https://datatracker.ietf.org/doc/html/rfc1925 comes to
> mind...
>
> Thanks!
>
> Regards,
> --
> Fernando Gont
> Director of Information Security
> EdgeUno, Inc.
> PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
>
>
>
>