RFC 3424 (rfc3424) - Page 3 of 9

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

RFC 3424        IAB Considerations for UNSAP Across NAT    November 2002


   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
      server are required to maintain information about the presumed
      state of the communication in order to manage the address
      illusion.

   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.






Daigle & IAB                 Informational