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

Generally I support the draft, but I also agree with comments about
firewalls.

To make this idea work, I would suggest changing word "must" to word
"SHOULD" in definition of Hdr Options parameters.
Designers of these additional headers have to acknowledge the fact that
there is no guarantee of delivery of unknown headers over firewalls in any
case.

I also have concern about mandatory "ICMP Parameter problem" message
required by second bit in the Hdr Options. While generally this is a nice
idea, it could be abused to start a reflection attack. Obviously in real
life this will be mitigated by control plane policing and other
traditional security measures, but draft does not permit that.
Replacing "must" with a "SHOULD" will fix this problem as well.

Have you considered an option to allow a device that does not understand
extension header to remove just the unknown header and continue processing
the packet?

Best Regards,
Yaroslav

On 4/1/11 12:43 AM, "Fernando Gont" <fernando@gont.com.ar> 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,
>-- 
>Fernando Gont
>e-mail: fernando@gont.com.ar || fgont@acm.org
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------