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

[Fernando Gont <[e-mail]>]

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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1