On Tue, Dec 4, 2018 at 8:10 PM Joe Touch <touch@xxxxxxxxxxxxxx> wrote:
On Dec 4, 2018, at 12:17 PM, Christopher Morrow <morrowc.lists@xxxxxxxxx> wrote:On Tue, Nov 27, 2018 at 5:40 AM Joe Touch <touch@xxxxxxxxxxxxxx> wrote: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.
So, perhaps I'm not expressing my point properly... I'll try again in a different way.
I don't think that they can be meaningfully throttled, no. I think that they will 'always' be throttled if they can not go on the fast-path, because the difference between 'fast-path' and 'not fast-path' is ~9 orders of magnitude. There's not a sane "welp, 50% of bandwidth" or anything like that possible in this scenario. Except: "meh, just pass along all packets unchecked, no HBH checking/evaluation nothing".
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”.
I don't think that's what I said, what i said is that loss of control-plane functionality is a security risk, because you lose availability.
Yes, that's not a 'big surprise', it's just a fact of life on the public network, to operate a network connected to the public you don't let things poke at your control-plane.
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.
'you' (the royal, not you in particular) may not consider loss of availability to be a security concern, but I expect all network operations folk to consider it such.
I expect that, by and large, folk who operate networks aren't trying to make 'your' (royal again) life hard here, 'we' (royal) are just saying: "there's a tradeoff, let's be sure we agree what the costs are going to be"
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.
it's a loss of availability for the users of the expected packets. It's not really "my" concern, unless I'm trying to do some new protocol thingy.
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.
can you expand on this some?
Joe
