Hi. I liked most of your suggestions for the UNSAF document. I'd like to comment further on two or three things: > Also from section 2: > > > > o absent "middlebox communication (midcom)" there is no usable way > > to let incoming communications make their way through a firewall > > under proper supervision: that is, respecting the firewall > > policies and as opposed to circumventing security mechanisms. The > > danger is that internal machines are unwittingly exposed to all > > the malicious communications from the external side that the > > firewall is intended to block. This is particularly unacceptable > > if the UNSAF process is running on one machine which is acting on > > behalf of several. > > I contend this is not a problem posed only by UNSAF processes. > Firewalls that filter at the Internet and transport layers have > performance requirements for enforcing access control policies on > incoming communications even when only one address realm is involved. > > I don't see how the presence of NA[P]T in a firewall substantially > alters these requirements. the difference is this - a firewall presumably gives you the ability to set policy about what kind of traffic is permitted - so you can choose which applications work and which fail according to your estimate of the benefit and risk that each presents. a NAT makes an entire class of applications fail whether you want them to fail or not - once you install the NAT, you have little further choice about whether those applications fail. (yes, I know you can often nail up a address binding, but this doesn't solve most of the problems, and it only works for a small number of hosts behind a NAPT) 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?) (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) > > 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. 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. > This scenario reminds me of a similar one I've observed in a > depressingly large number of home networks in which the wireless access > point product I helped develop has been installed by novice users. > > Here is the scenario which is most familiar to me: > > o the customer has existing Internet service from some broadband > service provider, using e.g. a DSL line connected to an > appliance that integrates a DSL modem with a NAPT router/firewall. > > o these devices are sometimes packaged with automated provisioning > firmware, so the customer may view them as part of what their > ISP provides them. > > o later, the customer wants to use a host with only a wireless LAN > interface; so, they install a wireless access point (like the > one I helped to develop) that ships in its default configuration > with NAPT and a DHCP server enabled. > > o after this, the customer has a wired LAN in one private address > realm and a wireless LAN in another private address realm. > > Furthermore, most customers probably have no idea what the phrase > "address realm" means, and shouldn't have to learn it. All they often > know is that the printer server is inaccessible to the wireless laptop > computer. (Why? Because the discovery protocol uses UDP multicast with > TTL=1, but that's okay because any response would just be dropped by the > NAPT anyway, because there's no ALG.) I'd say that "why" is because NAPT+(PPP/DHCP) is a poor solution to plug-and-play autoconfiguration of networks. autoconfiguration is a difficult problem, especially across multiple LANs, but what your scenario illustrates (IMHO) is that we need to find better ways of doing this than NAT. even though NAT might be useful in some cases, the choice should always be explicitly made by the user (hopefully with knowlege of the consequences) - a network hub or router should not "have to" do NAT in order to provide its hosts with connectivity. Keith