RFC 3424 (rfc3424) - Page 3 of 9
IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
Alternative Format: Original Text Document
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