Network Working Group L. Daigle, Ed. Request for Comments: 3424 Internet Architecture Board Category: Informational IAB November 2002 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
AbstractAs a result of the nature of Network Address Translation (NAT) Middleboxes, 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 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 proposal.
allocating an address in the realm that is external to the NAT box; and 2) 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, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available. 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 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.
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 service. o limiting the scope to outbound requests for service (or service initiation) in order to prevent unacceptable security exposures.
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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.