Subject: filtering packets with unknown options

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Jul 2006 11:33:27 -0400

After thinking about this a little more, it occurs to me that the  
correct behavior in cases where an unknown option is encountered and  
the security environment is such that this is deemed undesireable, is  
to drop the OPTION, not the packet.

This way, new stuff can be deployed without problems.

There is of course the tiny detail of how to implement this.  
Firewalls do a lot of processing so it's not completely outside the  
realm of possibility to assume that they could remove extension  
headers, but routers certainly aren't going to do this.

An alternative would be to set the contents of the option to all zero  
bits, this should be easier to implement than removing the header  
from the packet.

Thoughts?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jul 2006 19:58:32 +0300 (EEST)

On Wed, 12 Jul 2006, Iljitsch van Beijnum wrote:
> There is of course the tiny detail of how to implement this. Firewalls do a 
> lot of processing so it's not completely outside the realm of possibility to 
> assume that they could remove extension headers, but routers certainly aren't 
> going to do this.

This has been a no-no in IPv6 design.  Intermediary devices do not add 
or remove options.  That might even be explicitly stated in RFC 2460.

On the other end, FW _could_ send a parameter problem (or whatever) 
ICMP error about the packet, which could result in the host trying to 
send without the header (if the host included the logic to respond to 
failures to communicate with a header, which I'd assume they'd need to 
have in the future, e.g., with shim6).

However, I suspect many FW admins prefer silent discard in this case. 
I personally have no strong preference.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Eric Vyncke <[email-masked]>
Date: Wed, 12 Jul 2006 19:13:38 +0200

At 19:58 12/07/2006 +0300, Pekka Savola wrote:
>>There is of course the tiny detail of how to implement this. Firewalls do a lot of processing so it's not completely outside the realm of possibility to assume that they could remove extension headers, but routers certainly aren't going to do this.
>
>This has been a no-no in IPv6 design.  Intermediary devices do not add or remove options.  That might even be explicitly stated in RFC 2460.
>
>On the other end, FW _could_ send a parameter problem (or whatever) ICMP error about the packet, which could result in the host trying to send without the header (if the host included the logic to respond to failures to communicate with a header, which I'd assume they'd need to have in the future, e.g., with shim6).
>
>However, I suspect many FW admins prefer silent discard in this case. I personally have no strong preference.

And those FW admins will be right because this may end up in a reflection DoS attack ;-)

-éric

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Jul 2006 13:44:55 -0400

On 12-jul-2006, at 12:58, Pekka Savola wrote:

>> Firewalls do a lot of processing so it's not completely outside  
>> the realm of possibility to assume that they could remove  
>> extension headers, but routers certainly aren't going to do this.

> This has been a no-no in IPv6 design.  Intermediary devices do not  
> add or remove options.

Where is this documented?

> That might even be explicitly stated in RFC 2460.

No, doesn't look that way.

But firewalls break our architecture all the time, firewall admins  
don't seem to care.

Also, it would be possible to make new headers in a way that allows  
older firewalls to determine how to handle them, so zero out yes/no  
could be part of the header spec and thus be ok if so indicated.

> ICMP error about the packet, which could result in the host trying  
> to send without the header

This is what RFC 2460 says hosts should do:

    If, as a result of processing a header, a node is required to  
proceed
    to the next header but the Next Header value in the current  
header is
    unrecognized by the node, it should discard the packet and send an
    ICMP Parameter Problem message to the source of the packet, with an
    ICMP Code value of 1 ("unrecognized Next Header type encountered")
    and the ICMP Pointer field containing the offset of the unrecognized
    value within the original packet.  The same action should be  
taken if
    a node encounters a Next Header value of zero in any header other
    than an IPv6 header.

So it makes sense that if a firewall does this on behalf of the host,  
it does the same thing. But then it would have to spoof the source  
address of the original destination host, of course.

Note that for the destination options header we already have:

    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

       00 - skip over this option and continue processing the header.

       01 - discard the packet.

Last but not least, lest I forget: since there is no fixed header  
layout, it's impossible to determine what follows an unknown header.  
So you won't be able to filter on TCP/UDP info if there is an unknown  
header present.

> However, I suspect many FW admins prefer silent discard in this  
> case. I personally have no strong preference.

But how can you reasonably expect to ever deploy any new options/ 
headers when this happens??

But then again historically, firewalls have broken MANY things, such  
as EDNS0...

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Jul 2006 14:16:58 -0400

> headers, but routers certainly aren't going to do this.

There are router implementations that implement a variety of  
firewall. I don't see any reason they couldn't, apart from the DOS  
implications (which firewalls have as well).

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 Jul 2006 15:05:03 -0400

On 12-Jul-2006, at 11:33, Iljitsch van Beijnum wrote:

> An alternative would be to set the contents of the option to all  
> zero bits, this should be easier to implement than removing the  
> header from the packet.

For clarity, I presume you mean set the option type in each TLV the  
firewall is unhappy about (in all options extension headers that  
might be present) to zero ("skip this option").

It all still smells a bit nasty, though.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Jul 2006 19:43:27 -0400

> might be present) to zero ("skip this option").

Right, although "TLV" isn't exactly a given.

> It all still smells a bit nasty, though.

It is not a very pretty solution, but the alternative is that it will  
be extremely hard to the point of almost being impossible to deploy  
new "stuff" on the internet. Point in case is the "partial ECN" or  
something very similar that I can't find any reference to right now.  
The idea is to steal the last unused bit in the IPv4 header to extend  
the ECN semantics (the "evil" bit...) but IPv6 doesn't have this bit  
so that means an extra header, either a new one or a new option in  
the destination options header, I forget which. With firewalls  
filtering this out, this means a many-year uphill battle before this  
can be deployed.