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