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

[Fernando Gont <[e-mail]>]

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


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