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

[Fernando Gont <[e-mail]>]

Hi, Gorry,


On Thu, 2021-06-10 at 09:04 +0100, Gorry Fairhurst wrote:
> * Section 4, page 4:
> > 
> > >   The changes meant that an implementation complied with the IPv6
> > >   specification even if it did not process hop-by-hop options,
> > > and
> > > that
> > >   it was expected that routers would add configuration
> > > information to
> > >   control which hop-by-hop options they would process.
> > 
> > The way I interpret RFC8200 is that a router is configured whether
> > it
> > needs to process the HbH header in the first place, rather than
> > whether
> > to process specific options.
> > 
> I see, I don't see RFC8200 as saying whether this has to be a global 
> "switch"
> 
> to disable processing, or whether it allows configuration that can
> result
> 
> in disabling. This ID intends to update and clarify that aspect.

Fair enough. From my pov, I might live with simply skupping the HbH,
but wouldn't have my boxes parse its contents. -- i.e., either ignore
the whole thing, or drop. :-)



> > * Section 4, page 5:
> > 
> > >     There has been research that discussed the general problem
> > > with
> > >     dropping packets containing IPv6 extension headers, including
> > > the
> > >     Hop-by-Hop Options header.  For example [Hendriks] states
> > > that
> > >     "dropping all packets with Extension Headers, is a bad
> > > practice"
> > 
> > Given the number of vulnerabilities associated with the processing
> > of
> > IPv6 EHs, and that it's a feature that is largely unused, the
> > converse
> > is probably true.
> > 
> I thought you'd say so. However, this is a proposal to simplify the
> method
> 
> and to enable them to be used. I don't agree that this is generally 
> unsupported
> 

FWIW, my point is that a claim such as "dropping all packets with EHs
is abad practice" is kind of flawed/bogus statement.  -- it kind of
implicitly assumed that it's the result of an arbitrary decision. ..
when in many cases it's actually the other wat around.




> and I suggest yoy
> 
> > * Section 4, page 5:
> > 
> > This discussion misses an important point/aspect: the lgnth of the
> > IPv6
> > header chain. e.g., asking nodes to support a single HbH option if
> > such
> > option is, say, 256 bytes, will still be unfeasible.
> > 
> Are you saying the first option (HBH has to be first), is not within
> the
> 
> first 256 bytes? I don't understand.


What I mean is: one of the problematic aspects is the overall IPv6
header chain length. No matter the restriction on the number of HbH
instances or number of HbH options, if the overall IPv6 header chain
length is too long, you;ll be in trouble.

THe definition of too long depends on the implementation, and can be
anything from 8 to, say, 512, in powers of 2.  -- see RFC7872 for hint
of the impact of the IPv6 header chain length on the drop rate.





> > * Section 5.1, page 6:
> > > [RFC8200] also requires
> > >     that a Hop-by-Hop Options header can only appear once in a
> > > packet.
> > 
> > This doesn't seem accurate. 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.
> > 
> > i.e., there's a recommendation to send only one HbH, but still
> > required
> > to process all received. (cursed by the robustness principle, if
> > you
> > wish :-) )
> > 
> The proposed ID targets PS to change this.

What I mean is that the I-D argues that RFC8200 states that there can
only be one instance of HbH. However, it actually simply *recommends*
to have a single instance, but requires that any number of HbH
instances are accepted and processed (hence my reference to the
robustness principle)



> > * Section 5.3, page 8:
> > 
> > >        The Router Alert Option is a problem since it's function
> > > is to
> > > do
> > >        what this specification is proposing to eliminate, that
> > > is,
> > >        process the packet in the Slow Path.  One approach would
> > > be to
> > >        deprecate it as it's usage appears to be limited and
> > > packets
> > >        containing Hop-by-Hop options are frequently dropped.
> > 
> > Nore: This option is employed for MLD packets, which result from ND
> > using multicast. In such scenarios (MLD is link-local) packets
> > survive
> > -- cause they don't need to be forwarded in the first place.
> > Whether
> > using RAO for MLD (or whether MLD itself) is a good idea, is a
> > different question... ;-)
> Sure, isn't a Router Alert also used hop-by-hop with MPLS, RSVP for
> QoS, 
> and other methods?

Yep. What I'm saying is that it is actually used. So.. how/why would
you deprecate it?




> > 
> > * Section 8, page 10:
> > 
> > >     *  Limited the default number of Hop-by-Hop options that that
> > > can
> > > be
> > >        in a packet to a single Hop-by-Hop option.
> > 
> > If you are pursuing that path, you should also limite the overall
> > IPv6
> > header chain length. That;s probably even more important than
> > limiting
> > the number of EHs or number of HbH options.
> > 
> Why does that impact the ability to process a HBH-O in a router?


It doesn't. It affects the ability of the router to obtain layer-4
information from the packet. And when that happens, as per draft-ietf-
v6ops-ipv6-ehs-packet-drops, packets get dropped. That leads to
unreliability of HbHs, which affects their possible usage.

Thanks!

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