On Tue, Dec 4, 2018 at 8:10 PM Joe Touch <[email protected]> wrote:
> > > On Dec 4, 2018, at 12:17 PM, Christopher Morrow <[email protected]> > wrote: > > > > > > On Tue, Nov 27, 2018 at 5:40 AM Joe Touch <[email protected]> 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 >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
