Hi, Joel, On 03/01/2011 06:53 p.m., Joel M. Halpern wrote: > 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.
I think we're talking about different issues here. The goal of this document is to "help" firewalls such that they can get to the transport protocol (*assuming* that the firewalls do not care about extension headers). -- and my point is that you don't need to do this. -- if the extension header is unknown, the firewall should not allow the packet through (i.e., default deny). The fact that the firewall cannot *parse* the header is a secondary issue. -- And all this has little or nothing to do with our ability to extend our protocols. Now, you may argue that a "default" deny limits our ability to extend our protocols. Strictly speaking, it doesn't -- it limits our ability to *deploy* them. But then, there's no reason (security-wise) for which an admin should allow a protocol to be deployed in his network without his prior consent. Yep... usability vs. security.... > Also, if we assume that no one will ever define any new extension > headers, then this work does not matter. Even then, why not just mandate that new extension headers (if they ever need to be defined) should be TLV? -- why do we need the extra header, etc.? > 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. Just mandating that future extension headers have a syntax of TLV would suffice. Anyway, the rationale is that a firewall will allow stuff that it *needs* to allow. -- Why should a firewall allow an extension header that has not been deemed as necessary? >(Remember, these are for end-point consumption only.) NIDS, firewalls, and other middle-boxes consume these things.. even when they are not meant for them.... > 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. Just mandate TLV, and that's it -- actually, not sure why this is not part of RFC 2460 alreay... > 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. Such as? Thanks! Kind regards, -- 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 --------------------------------------------------------------------
