On Tue, Dec 4, 2018 at 11:32 PM Joe Touch <[email protected]> wrote:
> > > On Dec 4, 2018, at 8:11 PM, Christopher Morrow <[email protected]> > wrote: > > That works only for HBH options of type 00. Others require particular >> actions when not supported. >> >> > can you expand on this some? > > > Nobody deprecated the flags that require HBH options to be processed or > dropped if not supported. > > Oh, you are highlighting the difference between the 'theory' and 'practice'. ok. > And if there is a security risk to the control plane, it is using that > place for slow path processing without properly limiting its use of shared > resources. > > sure, that's a fine point. Doesn't actually change the state of the world where: "If your control-plane collapses, you have an unavailability event" which is a security problem. It's also an operational problem and likely a cost problem :( but... maintaining availability is part of what a good isp security group will do for the isp. > This idea that packets processed as intended are a security risk is like > saying big packets are a security risk to small packets. It may be a bad > design but it doesn’t mean such packets are inherently a security risk. > > it seems weird that in this case 'this is not a security problem', but sending a packet that breaks some assumptions in the applications at the end points and causes unexpected problems with the end point(s) (say sql injection in a web server or breaking some ssh server through some vulnerability) is a security problem? Instead of rat-holing on this point though, don't you actually care that the end points can do their work regardless of the network devices? (smart edges, dumb core ... that sort of thing) -chris
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
