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

["Christian Huitema" <[e-mail]>]

Tuesday, September 20, 2016 3:42 PM, Brian E Carpenter wrote:
> ...
> 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?

No. We should be chasing covert channels and eliminating them. AFAIK, our implementation of Teredo does not send any extra bytes after the "no next header."
 
> Do we know whether current firewalls tolerate it?

No idea. But they probably should not.

I would suggest replacing the text by "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, the packet should be rejected." Or something like that.

> 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.

We could add some text about packet length discrepancy. Something like "Firewalls and other devices should detect the presence of a hidden communication channel if the length of the concatenated headers does not match the length of the IPv6 payload. Such packets MAY be rejected."

-- Christian Huitema