If we take the view that a firewall will block anything it does not
know, without question or limit, then
1) We have no way to extend our basic protocols that will pass through
firewalls (we have to tunnel / encapsulate)
2) you are correct that this document does not help.
Also, if we assume that no one will ever define any new extension
headers, then this work does not matter.
(If we want that prohibition to be the case, we should say so, and
remove the hook for new extension headers that was left in 2460.)
On the other hand, if we think that there will be new extension headers,
and we think that firewalls block things if they can not find enough
information to allow them through, then it can be helpful if the
firewalls (and other devices) can parse pass these new extensions
without knowing them. (Remember, these are for end-point consumption only.)
It seems to me a disservice to simultaneously let people use new
extension headers and not give them a way to use them that can be parsed
past by the common devices that could easily want to do such parsing.
My own preference would probably be to say that all end-to-end IP
information should be in the destination options. But if we do not want
to go there, then we should own up to the implications thereof. (In
particular, there might be corner cases that can't use destination
options. We should tell people to use destination options first. And
tell them what to do if they can't.)
Yours,
Joel
On 1/3/2011 4:43 PM, Fernando Gont wrote:
On 03/01/2011 06:25 p.m., Brian E Carpenter wrote:
The basic motivation for the present draft is clear:
However,
some intermediate nodes such as firewalls, may need to look at the
transport layer header fields in order to make a decision to allow or
deny the packet.
That is, help middleboxes to violate e2e transparency and, furthermore,
allow unknown headers to cross those middleboxes.
I don't think this I-D will make a difference.
From the POV of a firewall, unless it really wants a packet to
pass-through, it will block it.
So, whether the Extension Header is unknown, or whether
draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is
unknown will lead to the same result: the packet will be discarded.
This proposal would only be useful to firewalls that implement a
"default allow", and that simply want to somehow ignore an unknown
extension header and base their decision on the upper-layer protocol
(only). -- But we all know that firewalls operate (or should operate) in
"default deny" rather than "default allow".
So IMHO this proposal won't be useful for such firewalls.
Thanks,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
