> On Nov 9, 2019, at 4:49 PM, Ole Troan <[email protected]> wrote: > > > >> On 9 Nov 2019, at 22:35, Bob Hinden <[email protected]> wrote: >> >>>>>> The hop-by-hop options header, when present in an IPv6 packet, forces >>>>>> all nodes in the path to inspect this header in the original IPv6 >>>>>> specification [RFC2460]. This enables denial of service attacks as >>>>>> most, if not all, routers cannot process this kind of packets in >>>>>> hardware but have to 'punt' this packet for software processing. > > I believe this statement is far out of date. > I would recommend getting recent data on this or delete it. > > Cheers > Ole This draft expired late 2016 so only few years old on this subject. https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 So I think the main issue with hbh is that even on the latest modern high end routers that process everything in hardware in the forwarding plane that hbh processing had to be sent to the control plane because some hbh options are used in the forwarding plane like jumbo frames, while others are to be consumed by the control plane such as router alert. Older routers forwarded all hbh from the forwarding plane to the control plane which now newer routers don’t do so but you still have hbh options that have to be consumed by the control plane. Excerpt from the draft above. Many modern routers maintain a strict separation between forwarding plane hardware and control plane hardware. In these routers, forwarding plane bandwidth is plentiful, while control plane bandwidth is constrained. In order to protect scarce control plane resources, these routers enforce policies the restrict access from the from the forwarding plane to the control plane. Effective policies address packets containing the HBH Options Extension header, because HBH control options require access from the forwarding plane to the control plane. Many network operators perceive HBH Options to be a breach of the separation between the forwarding and control planes [I-D.ietf-v6ops-ipv6-ehs-in-real-world]. Therefore, some network operators discard all packets containing the HBH Options Extension Header, while others forward the packets but ignore the HBH Options. Still other operators severely rate-limit packets containing the HBH Options Extension Header. In addition, some (notably older) implementations send all packets containing a HBH header to the control plane even if they contain only pad options, resulting in an effect DoS on the router and inconsistent drops among those packets due to rate limiting or other factors. [RFC7045] legitimizes the current state of affairs, severely limiting the utility of HBH options. In the words of RFC 7045: "The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in RFC2460. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a Hop-by-Hop option need to be aware of this likely behaviour." https://tools.ietf.org/html/rfc7045 2.2. Hop-by-Hop Options The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour. As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present, must be first. We should reference these two documents in this draft which I have to check.
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
