friends--
I have some commentary to offer on draft-iab-unsaf-
considerations-01.txt, i.e. "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF)" which comes from my experience developing a
consumer network appliance that combines the functions of an 802.11b
access point with a NAT router for Internet access.
From section 2:
>
> o there *is* no unique "outside" to a NAT -- it may be impossible to
> tell where the target UNSAF partner is with respect to the source;
> how does a client find an appropriate server to reflect its
> address? (See Appendix C).
>
> o specifically because it is impossible to tell where "outside" or
> "public" is, an address can only be determined relative to one
> specific point in the network. If the UNSAF partner that
> reflected a client's address is in a different NAT-masked subnet
> from some other service X that the client wishes to use, there is
> _no_ guarantee that the client's "perceived" address from the
> UNSAF partner would be the same as the address viewed from the
> perspective of X. (See Appendix C).
These two paragraphs are confusing to me. The explanation in Appendix C
helps to clarify the issue, but I would suggest rewriting them along the
following lines:
o a NAT may be a gateway between two or more private address realms,
with another NAT optionally used to gateway to the public Internet
realm; therefore, it may not always be possible to fix a transport
address to the correct realm (or realms) for a given instance of
an UNSAF process. (See Appendix C).
o there is no system for identifying address realms; therefore,
even if there were a mechanism for UNSAF processes to reflect
their transport addresses correctly in all appropriate realms,
the address of a service from the perspective of a client in one
realm is not comparable with the address of the same service
from the perspective of a client in another realm.
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.
Again from section 2:
>
> o proposed workarounds include the use of "ping"-like packets as
> traffic to the target service in order to determine the source
> address from the perspective of the target. However, there is no
> guarantee that the address translation will be constant throughout
> the course of the communication between endpoints; aging of NAT
> UDP bindings varies widely.
This is another paragraph that is confusing to me. I think it's because
the word "target" is used in way that makes it hard to understand in
context.
I'd prefer to see this written as follows:
o proposed workarounds include the use of "ping"-like address
discovery requests sent from the initiator to the listener, to
which the listener responds with the transport address of the
initiator-- in the address realm of the listener; however, with
connection-less transports, e.g. UDP, IPsec ESP, etc., an UNSAF
process must take care to react to changes in NAT bindings for
a given application flow, since it may change unpredictably
over time.
From section 3, Practical Issues:
>
> From observations of deployed networks, there is a wide variety of
> practice in how different NA[P]T boxes implement the handling of
> different traffic and addressing cases.
>
> Some of the specific types of observed behaviors have included:
> [...]
I would add the following to the list of observations:
o most NAPT implementations with ALGs that attempt to translate
TCP application protocols do not perform their functions
correctly when the substrings they must translate span across
multiple TCP segments; some of them are also known to fail on
flows that use TCP option headers, e.g. timestamps.
o many NAPT implementations include a "connect on demand" feature
for dialup PPP (as well as PPPoE/DSL) to Internet service
providers that dynamically assign addresses at connection time;
in these usage cases, UNSAF processes cannot obtain a fix on
their public transport address until they successfully negotiate
a PPP connection-- often requiring a significant delay,
especially in the case of dialup modem service.
Also, I think it would be helpful to know how commonly twice-NAT is
deployed, but I don't have any data there.
From section 4:
>
> By distinguishing these approaches as short term fixes, the IAB
> believes the following considerations must be explicitly addressed in
> any proposal:
>
> 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).
> 2. Description of an exit strategy/transition plan. The better
> short term fixes are the ones that will naturally see less and
> less use as the appropriate technology is deployed.
>
> 3. Discussion of specific issues that may render systems more
> "brittle". For example, approaches that involve using data at
> multiple network layers create more dependencies, increase
> debugging challenges, and make it harder to transition.
>
> 4. Identify requirements for longer term, sound technical solutions
> -- contribute to the process of finding the right longer term
> solution.
>
> 5. Discussion of the impact of the noted practical issues with
> existing, deployed NA[P]Ts and experience reports.
Good luck selling the rest of these.
Here's an idea for a consideration, in case some or all of the
considerations above don't gain any traction with the participants in
IETF working groups:
6. Precise description of the specific, general-scope, long-term
problems deliberately left unsolved with the UNSAF proposal.
From Appendix C:
>
> Here is one sample scenario wherein it is difficult to describe a
> single "outside" to a given address realm (bridged by NAPTs). This
> sort of configuration might arise in an enterprise environment, where
> different divisions have their own subnets (each using the same
> private address space); the divisions are connected so that they can
> pass traffic on each others' networks, but to access the global
> Internet, each uses a different NAPT/firewall.
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.)
It's very easy to configure most wireless access points as simple
bridges from 802.11b to Ethernet, but-- for some reason-- many customers
go for months, putting up with inconvenience after inconvenience, until
they finally encounter a problem that can only be solved by calling
customer care; at which point, they *might* learn about the magic
checkbox that turns off the NAPT.
The point I'm trying to make here: this scenario is probably more common
than the one described in Appendix C. It's also an example of NAPT
usage that arises more often by accident, rather than to solve a
particular, limited-scope problem-- which, I think poses an
architectural issue all its own.
--
j h woodyatt <jhw@wetware.com>