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

[Fernando Gont <[e-mail]>]

On 02/08/2015 04:24 PM, Ted Lemon wrote:
> On Feb 8, 2015, at 1:47 PM, C. M. Heard <[e-mail]> wrote:
>> It is not necessarily true that an unknown upper layer protocol 
>> header will look like a malformed extension header to a device that
>>  assumes it is an extension header following the format in RFC
>> 6564. If the value of the 2nd octet of the unknown header is v,
>> then it won't appear malformed if at least 8*(v+1) bytes remain in
>> the packet, starting from the beginning of the unknown header.  At
>> that point the device would be interpreting the payload of the
>> unknown upper layer PDU as an extension header chain.  In the
>> benign case where the packet is a legitimate one with an upper
>> layer protocol unknown to the device, it is likely (but not
>> assured) that the chain would quickly terminate in something that
>> looks like a malformed extension header.  However, it would not be
>> difficult to craft a packet that makes a very long apparent header
>> chain.  Depending on how the device processes header chains, that
>> could easily be a vector for DOS attacks -- e.g., by consuming
>> processing resources or by exercising a rarely used processing
>> path.  That is why I think it is UNSAFE to continue processing a
>> header chain after encountering an unknown next header value.
> 
> This may or may not be true, but to the extent that it's true, it's
> already addressed in RFC 7045, and it's addressed correctly there.
> There is no need to strengthen the advice in RFC 7045 here, which
> this document currently does

Why do you think this document "strengthens the advice in RFC7045", as
opposed to it actually *complying* with what's in RFC7045?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492