Re: I-D Action:draft-ietf-6man-exthdr-01.txt

["Hing-Kam (Kam) Lam" <[e-mail]>]

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

I agree.

> 2) you are correct that this document does not help.

Disagree. If the Hdr Options is 00, then it will pass through.

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

Yes.

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

Yes.

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

This then could be added in the subsequent versions of this draft.

Kam

>
> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>