> On Nov 9, 2019, at 9:15 PM, Gyan Mishra <[email protected]> wrote: > > > > > >> 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.
Ole Thanks for the comments. I think the hbh section is most pertinent to this I-D. I will work with the authors to update with current data. Gyan >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
