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
