Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Mark Andrews <[e-mail]>]

> On 5 Dec 2018, at 4:37 pm, Christopher Morrow <[e-mail]> wrote:
> 
> 
> 
> On Tue, Dec 4, 2018 at 11:32 PM Joe Touch <[e-mail]> wrote:
> 
> 
> On Dec 4, 2018, at 8:11 PM, Christopher Morrow <[e-mail]> 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.

And the correct thing to do is to FIX THE BROKEN PRODUCT.  

If a ssh implementation is broken we don’t drop SSH packets.  We fix the broken implementation of ssh.

If there is a SQL injection problem we fix that problem rather than dropping HTTP
and HTTPS packets.

If a router can’t handle all legal packets at line rate the router needs to fixed.

Punting stuff to be processed by the same CPU that process the routing table worked
for a while.  There is no rule that says routers can’t have multiple CPUs some of
which are dedicated to handling the control plane and other that deal with everything
else that has been punted.  Design the router so that the control plane doesn’t get
overloaded and the exceptional packet get handled.

Generating PTB’s shouldn’t be seen as exceptional.  Fragmented packets shouldn’t be
seen as exceptional. 

> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]