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" <ferna...@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: ferna...@gont.com.ar || fg...@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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
