Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

On Feb 9, 2015, at 9:51 PM, C. M. Heard <[e-mail]> wrote:
> If I counted correctly, this "packet" uses all 110 unassigned 
> protocol numbers (aka next header values).  It would be easy to 
> include more or fewer headers.  Or make the last header length point 
> outside the packet.
> 
> Note that this is not an attack on the destination host.  The 
> destination host should drop the packet immediately upon 
> encountering an unknown next header value.  Rather, it is an attack 
> on the DHCPv6-Shield engine, which has to do a lot of work to figure 
> out what to do with this packet.  Is a typical implementation robust 
> enough to deal with a line-rate stream of stuff like this?  Do 
> implementations with hardware accelerators (and limited header 
> memory) suffer no adverse effects at all?  What do they do if the 
> header chain won't fit?  I'm sure the effects vary greatly, but is 
> is really true that this attack is nothing to worry about?

I think what will happen in practice is that there will be some fast-path logic that looks at the first 256 bytes of the packet at most, and probably discards it if it can't be made sense of by the end of those 256 bytes.   I am completely okay with that.   What I am not okay with is advocating this behavior in a BCP.

AFAIK existing implementations of DHCPv6-shield already do this.