ietf
[Top] [All Lists]

Re: draft-iab-unsaf-considerations-01.txt

2002-04-05 16:30:35
On Thursday, April 4, 2002, at 05:53 PM, Keith Moore wrote:
[I wrote:]
[...]
I don't see how the presence of NA[P]T in a firewall substantially
alters these requirements.

[...]
but I think the IAB were trying to say that it's important to make
sure that measures used to circumvent NAT problems do not essentially
end up violating site security policies.  an application that's
not allowed to talk through a firewall shouldn't be able to use the
NAT-workaround to enable it to do so.  (and if that's what they meant
to say, perhaps it can be said more clearly?)

If that's the case, then it wasn't clear to me in the draft. Perhaps one of the current members of the IAB would care to clarify this point before I offer to compose an alternative wording.

(but IMHO neither should the mere presence of a NAT be taken to mean
that there's a policy in place that prohibits incoming connections)

I rather liked the language your wrote in draft-moore-nat-tolerance-recommendations-00.txt about that. Perhaps UNSAF proposals should be structured so that they make no assumptions about whether the presence of NAPT does or does not imply a policy permitting or prohibiting any particular class of incoming connections. I'm not sure how to say that in a meaningful way.

   1.  Precise definition of a specific, limited-scope problem that is
       to be solved with the UNSAF proposal.   A short term fix should
       not be generalized to solve other problems; this is why  "short
       term fixes usually aren't".

For example, I suggest extensions to Internet application protocols for
UNSAF use (in an IPv4/NAT environment) should be preferred to
application protocols generalized for UNSAF use (over both IPv6 and IPv4
transports).

this seems like a overgeneralization, or maybe I don't understand you.

I suspect I wasn't communicating clearly.

the method that used to adapt an application to NATs will necessarily
vary significantly from one application to another, depending on
a wide variety of factors - the communications patterns, typical session
duration, deployment model (can the user reasonably be expected to install
a proxy?), consequences of failure, etc. of each application.
at the same time, a generalized approach can be applied to a significant
subset of applications, with a useful side effect of aiding a transition
to IPv6.  see draft-moore-nat-tolerance-recommendations-00 for a start.

I was specifically thinking about UNSAF processes, and all I was trying to do was ask the IAB to make a specific recommendation against the use of UNSAF processes in applications of IPv6 transports.

I've met too many people-- who are otherwise fairly smart-- who are absolutely committed to the notion that NAT devices will still be required to secure IPv6 networks. I don't understand them, and I think they're wrong about the security considerations of NAT, but I know they're out there.

-----

Another thing that springs to mind: the IAB should probably encourage-- in no uncertain terms-- that any UNSAF process specified for use with IPv4 NAT should also be specified for use with RFC 2766 "Network Address Translation - Protocol Translation (NAT-PT)" as well.


--
j h woodyatt <jhw(_at_)wetware(_dot_)com>