Security Considerations for Next Header value 59 [was Re: Review of draft-ietf-6man-rfc2460bis-05]

I realised that we probably have to discuss this further. There are two
places where rfc2460bis explicitly allows a covert channel because of
No Next Header:

> 4.5.  Fragment Header
...
>       The Fragmentable Part consists of the rest of the packet after the
>       upper-layer header or after any header (i.e., initial IPv6 header
>       or extension header) that contains a Next Header value of No Next
>       Header.
...
> 4.7.  No Next Header
> 
>    The value 59 in the Next Header field of an IPv6 header or any
>    extension header indicates that there is nothing following that
>    header.  If the Payload Length field of the IPv6 header indicates the
>    presence of octets past the end of a header whose Next Header field
>    contains 59, those octets must be ignored, and passed on unchanged if
>    the packet is forwarded.

Do we really want to allow this? Do we know whether current firewalls
tolerate it?

If we keep this, I think some words about the covert channel are needed
in the Security Considerations.

And looking at the Security Considerations, I don't think they are
sufficient anyway. At the least we should refer to other work, not
just IPSec.

Regards
   Brian

On 01/09/2016 08:32, Brian E Carpenter wrote:
> On 31/08/2016 20:30, Tim Chown wrote:
>> On 30 Aug 2016, at 22:41, huitema@huitema.net<mailto:huitema@huitema.net> wrote:
>>
>> It is used in Teredo. The Teredo bubbles have no payload, hence set payload type to 59.
>>
>> OK, thanks, that seems a reasonable generic use case, even if there’s only one example :)
>>
>> But given it’s not in RFC 7045, anyone kind enough to implement the advice there won’t necessarily include header 59.
> 
> Actually it is mentioned in 7045 but intentionally not listed in the IANA registry:
>    "This list excludes type 59, No Next Header, [RFC2460], which is not
>    an extension header as such."
> 
> Packets with "No Next Header" followed by additional bytes are allowed by RFC2460,
> but would be very suspect to any firewall, I would think.
> 
>     Brian
> 
>>
>> Tim
>>
>> Sent from my Windows 10 phone
>>
>> From: Brian E Carpenter<mailto:brian.e.carpenter@gmail.com>
>> Sent: Tuesday, August 30, 2016 1:40 PM
>> To: Bob Hinden<mailto:bob.hinden@gmail.com>; Tim Chown<mailto:Tim.Chown@jisc.ac.uk>
>> Cc: 6man@ietf.org<mailto:6man@ietf.org>
>> Subject: Next Header value 59 [was Re: Review of draft-ietf-6man-rfc2460bis-05]
>>
>> On 31/08/2016 08:19, Bob Hinden wrote:
>>
>> ...
>>>> p.22 is Next Header value 59 used in practice? (Just curious… it was omitted from RFC7045).
>>>
>>> I am not 100% sure, but think it is used.  But it is not something that has been updated.
>>
>> It's a curious case, but we didn't mention it in 7045 or ask IANA to include it in
>> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
>> because, well, it isn't a header and doesn't require any processing. I think
>> that's OK.
>>
>> Regards
>>      Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org<mailto:ipv6@ietf.org>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 