[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: filtering packets with unknown options

On 12-jul-2006, at 12:58, 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. 

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

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