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