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@wetware.com>