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

[Brian Haberman <[e-mail]>]

On 2/9/15 1:57 PM, Fernando Gont wrote:
> 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?

Perhaps the issue is that not everyone has read 7045 recently.  The
primary piece of advice in 7045 is section 2.1
(http://tools.ietf.org/html/rfc7045#section-2.1), which I summarize as:

1. A forwarding node SHOULD forward all packets regardless of whether
there are extension headers present or not.

2. If a forwarding node examines the packet it MUST recognize all
standard extension headers and SHOULD recognize all experimental
extension headers.

3. Intermediate nodes SHOULD NOT discard a packet containing
unrecognized extension headers.

4. If the intermediate node discards a packet containing a standard
extension header, it MUST be because of a configurable policy.

5. The discard policy for each standard extension header MUST be
individually configurable.  The default configuration SHOULD allow all
standard extension headers.

6. Forwarding nodes MUST be configurable to allow unrecognized extension
headers. The default configuration MAY be to drop packets containing them.

Regards,
Brian