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>