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

[Tom Herbert <[e-mail]>]

On Thu, Jun 10, 2021 at 12:41 AM Fernando Gont
<fernando.gont=[e-mail]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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.
>
>
> * 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.
>
>
> * 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.
>
>
> * 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 :-) )
>
>
> * 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....
>
>
> * 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... ;-)
>
>
> * 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?
>
>
> * 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.
>
Fernando,

That limit and other pertinent ones are defined in RFC8504 section 5.3
and RFC8883. The limits in RFC8504 are specified for hosts, but it
would be straightforward to apply them to routers  where the behavior
when a limit is exceeded would be different-- end hosts should drop
packets that exceed the limit, intermediate nodes should stop parsing
and forward the packet. If a node decides to drop the packet then it
can send an RFC8883 ICMP error to inform the sender what the exceeded
limit was. Recommended defaults can be provided for limits; e.g. in
RFC8504 the limit of HBH or DestOpts is eight meaning that receivers
should support up to eight options and senders should be able to send
up to eight options with reasonable confidence their packets won't be
dropped. A similar default could be established for length of IP
header chain (for hosts this isn't immediately necessary since hosts,
unlike routers, usually don't have a concept of fixed sized parsing
buffer holding headers, although with hardware acceleration that limit
might be more applicable to set in the host).

Tom

>
> Thanks!
>
> Regards,
> - --
> Fernando Gont
> Director of Information Security
> EdgeUno, Inc.
> PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iQFOBAEBCgA4FiEE371j47JIrnnFmK8j667aAwZEFTEFAmDBwgcaHGZlcm5hbmRv
> LmdvbnRAZWRnZXVuby5jb20ACgkQ667aAwZEFTH/qAf/Su1CoIjSBl6GeEIl0jn5
> JoW+H8uqAS49aP0pjFDsOXT2La5vGlT4DNDicextT5ca9xpI7BBBxxf8VDP1pdS6
> jgh/k2mp5qwGFG0UyJSIm46+hxW1+N6VbQ1RV19oKUFPk2iIcsPtimQuHIE/fa8I
> 1BD49ljp6WbZTR4DrqZFuKpbV8Zx5AxaOTGUuxzWEDzfOrylnmacPrT9IspbgU+R
> VIW6wMtHNK75LHs9ILSUjTGlv4056KrMkk9b/1Ot01wO7dgzFG6MXEQznVO1FUHX
> 8K9Y3+dB9yOg6cUenzDsCEqRgcnLPIXkbQhwySHQW9dAs0VkLwE8c+aKt9O5283W
> cQ==
> =u+vn
> -----END PGP SIGNATURE-----
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------