Take that to the standards wg. Don’t stick your head in the sand and try to do an end run in ops. And don’t call any of this a security issue that it isn’t.
Joe, I think one of the 3 pillars of security is: "Availability" (the other two are 'Confidentiality' and 'Integrity’)
It is...
I think the point that Nick and Gert are outlining is that if the case is that the hardware available will have no fast-path processing for packets with obtuse patterns or sets of extension headers those packets will get sent to the control-plane (slow-path). That slow-path being congested will cause availability problems.
If that happens, the packets with these headers can easily be throttled - thus avoiding a security issue.
However, what you’re basically saying is that “it is a security risk to send packets to a router because it might have to do work”. Yeah, big surprise. Either do the work or limit the impact. But that’s not the kind of security risk we associate with availability - a good example of which would be that sending a single packet would cause the work of 1000.
But none of that is happening here.
Actually, whether or not the control-plane fails under such load may not even matter, if the rate-limiting of the packets here is such that (as gert said) all but a trickle of the interesting packets are forwarded.
But then that’s not a security problem.
A solution might be to have a mode where a router may just ignore all headers except the src/dst-ip and simply forward all packets, trusting that the conversing adults will sort out problems with unknown/new/experimental headers or with a tortured ordering of headers (for instance). This will also cause some operational headaches: "Please drop all traffic toward ipX with protoY and dst-port Z" but perhaps it's still acceptable to some folk to operate like this?
That works only for HBH options of type 00. Others require particular actions when not supported.
