Internet DRAFT - draft-iab-unsaf-considerations


Network Working Group                                          L. Daigle
Internet-Draft                                                    Editor
Expires: December 27, 2002                   Internet Architecture Board
                                                           June 28, 2002

 IAB Considerations for UNilateral Self-Address Fixing (UNSAF)  Across
                      Network Address Translation

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 27, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   As a result of the nature of network address translation middleboxes
   (NATs), communicating endpoints that are separated by one or more
   NATs do not know how to refer to themselves using addresses that are
   valid in the addressing realms of their (current and future) peers.
   Various proposals have been made for "UNilateral Self-Address Fixing
   (UNSAF)" processes.  These are processes whereby some originating
   endpoint attempts to determine  or fix the address (and port) by
   which it is known to another endpoint -- e.g., to be able to use
   address data in the protocol exchange, or to advertise a public

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 1]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

   address from which it will receive connections.

   This document outlines the reasons for which these proposals can be
   considered at best as short term fixes to specific problems, and the
   specific issues to be carefully evaluated before creating an UNSAF

1. Introduction

   As a result of the nature of network address (and port) translation
   middleboxes (NATs), communicating endpoints that are separated by one
   or more NATs do not know how to refer to themselves using addresses
   that are valid in the addressing realms of their (current and future)
   peers -- the address translation is locked within the NAT box.  For
   some purposes, endpoints need to know the addresses (and/or ports) by
   which they are known to their peers.  There are two cases.  When the
   client initiates communication, starting the communication has the
   side effect of creating an address binding in the NAT device and
   allocating an address in the realm that is external to the NAT box.
   In the second case, a server will be accepting connections from
   outside, but because it does not initiate communication, no NAT
   binding is created.  In such cases, a mechanism is needed to fix such
   a binding, before communication can take place.

   "UNilateral Self-Address Fixing (UNSAF)" is a process whereby some
   originating process attempts to determine  or fix the address (and
   port) by which it is known -- e.g., to be able to use address data in
   the protocol exchange, or to advertise a public address from which it
   will receive connections.

   There are only heuristics and workarounds to attempt to achieve this
   effect; there is no 100% solution.  Since NATs may also dynamically
   reclaim or readjust translations, "keep-alive" and periodic re-
   polling may be required.  Use of these workarounds MUST be considered
   transitional in IETF protocols; a better architectural solution is
   being sought.  The explicit intention is to deprecate any such
   workarounds when sound technical approaches are available.

2. Architectural issues affecting UNSAF Systems

   Generally speaking, the proposed workarounds are for cases where a
   standard protocol communication is to take place between two
   endpoints,  but in order for this to occur, a separate step of
   determining (or fixing) the perceived address of an endpoint in the
   other endpoint's addressing realm is required.  Proposals require
   that an endpoint seeking to "fix" its address contact a participating
   service (in a different address realm) to determine (reflect) its
   address.  Thus, there is an "UNSAF client", partnering with some form

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 2]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

   of "UNSAF service" that may or may not be associated with the target
   endpoint of the actual desired communication session.  Throughout
   this memo, the terms "UNSAF server" and "UNSAF service" should be
   understood to generically refer to whatever process is participating
   in the UNSAF address determination for the originating process (the
   UNSAF client).

   Any users of these workarounds should be aware that specific
   technical issues that impede the creation of a general solution

   o  there *is* no unique "outside" to a NAT -- it may be impossible to
      tell where the target endpoint is with respect to the initiator;
      how does an UNSAF client find an appropriate UNSAF server to
      reflect its address?  (See Appendix C).

   o  specifically because it is impossible to tell where address realms
      are bounded ("inside" or "outside", "private" or "public", or
      several "private" realms routing traffic), an address can only be
      determined relative to one specific point in the network.  If the
      UNSAF service that reflected an UNSAF client's address is in a
      different NAT-masqueraded 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).

   o  absent "middlebox communication (midcom)" there is no usable way
      to let incoming communications make their way through a middlebox
      (NAT, firewall) under proper supervision.  By circumventing the
      NAT, UNSAF mechanisms may also (inadvertently) circumvent security
      mechanisms.  The particular 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.

   o  proposed workarounds include the use of "ping"-like address
      discovery requests sent from the UNSAF client (initiator) to the
      UNSAF server (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

   o  if the UNSAF client uses periodic retries to refresh/reevaluate
      the address translation state, both the UNSAF client and the UNSAF

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 3]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

      server are required to maintain information about the presumed
      state of the communication in order to manage the address

   o  since the UNSAF server is not integrated with the middlebox, it
      can only operate on the assumption that past behavior is a
      predictor of future behavior.  It has no special knowledge of the
      address translation heuristic or affecting factors.

   o  the communication exchange is made more "brittle" by the
      introduction of other servers (UNSAF servers) that need to be
      reachable in order for the communication to succeed -- more boxes
      that are "fate sharing" in the communication.

   Workarounds may mitigate some of these problems through tight scoping
   of applicability and specific fixes.  For example,

   o  rather than finding the address from "the" outside of the NAT, the
      applicability of the approach may be limited to finding the "self-
      address" from a specific service, for use exclusively with that

   o  limiting the scope to outbound requests for service (or service
      initiation) in order to prevent unacceptable security exposures.

3. Practical Issues

   From observations of deployed networks, there is a wide variety of
   practice in how different NAT boxes implement the handling of
   different traffic and addressing cases.

   Some of the specific types of observed behaviors have included:

   o  NATs may drop fragments in either direction:  without complete
      TCP/UDP headers, the NAT may not make the address translation
      mapping, simply dropping the packet.

   o  Shipping NATs often contain Application Layer Gateways (ALGs),
      which attempt to be context-sensitive, depending on the source or
      destination port number.  The behavior of the ALGs can be hard to
      anticipate, and these behaviors have not always been documented.

   o  Most NAT 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.

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 4]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

   o  NAT implementations differ markedly in their handling of packets.
      Quite a few only really work reliably with TCP.  If they do handle
      UDP, the timers aging out flows can vary widely.

   o  Variation in address and port assignments can be quite frequent --
      on NATs, port numbers always change, and change unpredictably;
      there may be multiple NATs in parallel for load-sharing, making IP
      address variations quite likely as well.

4. Architectural Considerations

   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".

   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

   5.  Discussion of the impact of the noted practical issues with
       existing, deployed NATs and experience reports.

5. Security Considerations

   As a general class of workarounds,  UNSAF proposals may introduce
   security holes because, absent "middlebox communication (midcom)",
   there is no usable way to let incoming communications make their way
   through a firewall under proper supervision:  respecting the firewall
   policies as opposed to circumventing security mechanisms.

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 5]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

Authors' Addresses

   Leslie Daigle

   Internet Architecture Board


Appendix A. IAB Members at the time of this writing

      Harald Alvestrand

      Ran Atkinson

      Rob Austein

      Fred Baker

      Leslie Daigle

      Steve Deering

      Sally Floyd

      Ted Hardie

      Geoff Huston

      Charlie Kaufman

      James Kempf

      Eric Rescorla

      Mike St.  Johns

Appendix B. Acknowledgements

   This document has benefitted greatly from detailed comments and
   suggestions from Thomas Narten, Bernard Aboba, Keith Moore, and James

   This document was originally drafted when the following people were
   part of the IAB:  Steve Bellovin, Brian Carpenter, Jon Crowcroft,

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 6]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

   John Klensin and Henning Schulzrinne; it has benefited considerably
   from their contributions and review.

Appendix C. Example NAT Configuration Scenario

C.1 Generic NATed Network Configuration

   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.

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 7]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

                                    | Box C   | (
                                   | NAT 2   |
              |                                      |
              |                                 +----+----+
              |                                 | Box B   | (
              |                                 +---------+
         | NAPT 1  | (
               | Box A   | (

   From the perspective of Box B, Box A's address is (some port on)  From the perspective of Box C, however, Box A's address
   is some address in the space

C.2 Real World Home Network Example

   James Woodyatt provided the following scenario, based on current
   examples of home networking products:

   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 NAT 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

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 8]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

      interface; so, they install a wireless access point that ships in
      its default configuration with NAT 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 NAT anyway, because there's no ALG.)

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 9]
Internet-Draft      draft-iab-unsaf-considerations-02          June 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Daigle & Internet Architecture Board    Expires December 27, 2002    [Page 10]