Re: Comments on <draft-gont-6man-rfc6564bis-01>

[Brian E Carpenter <[e-mail]>]

On 28/10/2015 06:32, Hagen Paul Pfeifer wrote:
>> On October 27, 2015 at 1:51 AM Brian E Carpenter
>> <[e-mail]> wrote:
> 
> Hey Brian
> 
>> That is 6 extension header types. There are 11 header types
>> currently registered:
>> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
>> .
>> Where does the code handle the other 5, and in particular how does it
>> handle the experimental values, whose structure is completely open?
> 
> The Linux Kernel must handle some types a little bit different. So for
> example see
> http://lxr.free-electrons.com/source/include/uapi/linux/in6.h#L130 and
> click on IPPROTO_MH you will find the code how IP Mobility is implemented.
> HIP and SHIM is not mainlined and not supported yet. Sure, a patch can
> help to make these extension headers known to let the kernel ignore them.
> If currently one of these extension header is received the packet will be
> discarded. Maybe this is an indicator that HIP/SHIM is not widely adopted.
> ;-) Note: "received" means in particular the packet is locally delivered.
> Let's skip the decision what happens to HIP/SHIM packets over netfiltered
> forwarding paths.

No, we can't skip it, because that's the point. Of course, the receiving host
must contain code for any extension headers it is supposed to understand.
Taking the example of shim6, if a receiving host has installed linshim6
it works just fine *except* that some annoying firewall on the path drops
all the packets. A firewall built on Linux will do that, judging by the code
extract you supplied.

> The experimental range is not supported because it is impossible! This is
> the central issue and it is addressed with this ID (among other things).
> Supporting the "experimental range" is not possible because the kernel do
> not know how the particular extension header is encoded! The kernel do not
> know how to jump over unknown extension header. 

Sure, if we're talking about the receiving host. But a firewall should be
configurable to allow the packet through. That's the point of RFC7045.

> What is required is a
> guarantee that a particular extension header is encoded in a pre-known
> format. This is where draft-gont-6man-rfc6564bis comes into play.
> 
> 1. Define a Universal Extension Header with a TLV like encoding where the
> header size is always at the same position
> 2. Provide the Kernel a guarantee that a header is encoded with the
> Universal Extension header

I think that buffer overflow attacks are built on the assumption that
such a 'guarantee' is meaningless. Isn't that the entire reason that firewall
people like to discard unknown headers?

   Brian