Subject: draft-iab-unsaf-considerations-01.txt

From: james woodyatt <[email-masked]>
Date: Thu, 4 Apr 2002 15:53:31 -0800

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 <[email-masked]>