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

[Gorry Fairhurst <[e-mail]>]

Hi Fernando,


On 10/06/2021 08:40, Fernando Gont wrote:

> Hi, Bob & Gorry,
>
> Some comments:
>
> * 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.

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

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.

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

> * Section 5.2, page 6:
>
> >    If the node can not process an option in the Fast Path, it MUST
> >    behave as if it does not recognize the Option Type (as described
> > in
> >    the next paragraph).
>
> My take is that a router that wouldn't be able to process options in
> the fast-path wouldn't even bother to parse the contents of the HbH in
> the first place....
>
I think we can trip-up easily on slow path and fast path terms, as we have

seen on this list.

>
> * 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?

> * Section 5.3, page 8:
>
>
> >    A Fast Path implementation SHOULD verify that a Router Alert
> > contains
> >    a protocol, as indicated by the Value field in the Router Alert
> >    option, that is configured as a protocol of interest to that
> > router.
> >    A verified packet SHOULD be sent on the Slow Path for processing
> >    [RFC6398].
>
> If the device knows it's not using a protocol that may need to rely on
> RAOs, why should the device parse, say, RAOs in the first place?
>
I'm OK with what you say.
>
> * Section 6, page 9:
> >    Any new IPv6 Hop-by-Hop option designed in the future should be
> >    designed to be processed in the Fast Path.  New options MUST NOT
> > be
> >    defined that require Slow Path processing.  New Hop-by-Hop options
> >    SHOULD have the following characteristics:
>
> >    *  Straight forward to process.  That is, they should be designed
> > to
> >       keep the time to process low.
>
> >    *  Fixed size in 8-octet units.  Specifically any new Hop-by-Hop
> >       options should not be variable size that could extend beyond
> > what
> >       can be executed in the Fast Path.
>
> This is missing the overall option length.
>
>
> * Section 8, page 10:
>
> >    Security issues with IPv6 Hop-by-Hop options are well known and
> > have
> >    been documented in several places, including [RFC6398], [RFC6192],
> >    and [I-D.ietf-v6ops-ipv6-ehs-packet-drops].  The main issue, as
> > noted
> >    in Section 4, is that any mechanism that can be used to force
> > packets
> >    into the router's Slow Path can be exploited as a denial of
> > service
> >    attack on a transit router by saturating the resources need for
> >    router management protocols (e.g., routing protocols, network
> >    management protocols, etc.) that may cause the router to
> > fail.  Due
> >    to this it's common for transit routers to drop packets with Hop-
> > by-
> >    Hop options headers.
>
> This discussion missess to note and acknowledge that there is a general
> issue associated with IPv6 extension headers.
>
> HbH has extra problems. But there are other general issues that apply
> to all EHs, and not just HbH.
>
>
> * 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?
>
> Thanks!
>
> Regards,

Best wishes,

Gorry