UNSAF considerations: IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
Why learning an outside address from behind a NAT is only a limited, transitional workaround.
Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <https://www.rfc-editor.org/info/rfc3424>.
@misc{rfc3424,
series = {Request for Comments},
number = 3424,
howpublished = {RFC 3424},
publisher = {RFC Editor},
doi = {10.17487/RFC3424},
url = {https://www.rfc-editor.org/info/rfc3424},
author = {L. Daigle and IAB},
title = {{IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation}},
pagetotal = 9,
year = 2002,
month = nov,
} RFC text
Contents
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.
Abstract
As 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.
1. Introduction
As a result of the nature of Network Address (and port) 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 - 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: 1) 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;
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.
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
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
include:
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
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.
3. Practical Issues
From observations of deployed networks, it is clear that different
NAT box implementations vary widely in terms of how they handle
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.
o NAT implementations differ markedly in their handling of packets.
Quite a few only really work reliably with TCP packets, not UDP.
Of the ones that do make any attempt to handle UDP packets, the
timers aging out flows can vary widely making it challenging to
predict behavior.
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. Such generalizations
lead to the the prolonged dependence on and usage of the supposed
short term fix -- meaning that it is no longer accurate to call
it "short term".
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
solution.
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, in the absence of "middlebox communication
(midcom)", there is no feasible way to let incoming communications
make their way through a firewall under proper supervision:
respecting the firewall policies as opposed to circumventing security
mechanisms.
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 benefited greatly from detailed comments and
suggestions from Thomas Narten, Bernard Aboba, Keith Moore, and James
Woodyatt.
This document was originally drafted when the following people were
part of the IAB: Steve Bellovin, Brian Carpenter, Jon Crowcroft, 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:
+---------+
| Box C | (192.168.4.5)
+---+-----+
|
---------------------------------+-------
|
| 192.168.3.0/24
+----+----+
| NAT 2 |
+----+----+
| 10.1.0.0/32
|
-----+-------------------------+------------+----
| |
| +----+----+
| | Box B | (10.1.1.100)
| +---------+
|
+----+----+
| NAPT 1 | (10.1.2.27)
+----+----+
| 10.1.0.0/32
|
----+-----+--
|
|
+----+----+
| Box A | (10.1.1.100)
+---------+
From the perspective of Box B, Box A's address is (some port on)
10.1.2.27. From the perspective of Box C, however, Box A's address
is some address in the space 192.168.3.0/24.
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
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.)
Authors' Addresses
Leslie Daigle
Editor
Internet Architecture Board
IAB
EMail: iab@iab.org
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.
ISO Plain Language
On this page
§1The Self-Address Problem
When one or more Network Address Translators (NATs) sit between two endpoints, the address translation is held inside the NAT. An endpoint may therefore not know the address and port that are valid from a peer's network. Unilateral Self-Address Fixing (UNSAF) describes attempts by an endpoint to discover or establish the address and port by which it is known.
A client that starts communication may create a NAT binding as a side effect. A server that only waits for incoming connections does not create one, so some mechanism would have to establish a binding before communication can start. The memo says there is no complete solution: translations can change or be reclaimed, requiring keep-alives or repeated checks.
The IAB says IETF protocols MUST treat these workarounds as transitional and intends to deprecate them when sound technical approaches are available.
A host behind a NAT may not know which address another host can use to reach it. A discovery trick may work only temporarily because the NAT can change or remove the address mapping.
§2Why Address Discovery Has Limits
An UNSAF client asks a service in another address realm to report the address it sees. That report is specific to the service's place in the network. There is no single, well-defined outside of a NAT, and a different service may see a different address for the same client.
The helper service is not integrated with the NAT, so it cannot know the NAT's rules or predict when a translation will change. Connectionless traffic such as UDP can be especially affected by changing bindings. Periodic refreshes also require both the client and service to track assumed communication state, and adding a helper creates another dependency that can fail.
Without middlebox communication (MIDCOM), a workaround may let incoming traffic bypass a NAT or firewall without respecting the firewall's policies. The memo says proposals can reduce some problems by limiting address discovery to one named service and restricting the method to outbound service requests.
A helper reports only the address it sees, and another service may see a different one. The helper also cannot control the NAT, while bypassing the NAT can bypass firewall protections.
§3Different NATs Behave Differently
The memo reports wide variation among deployed NATs. Some drop fragmented packets because they cannot make a mapping without complete TCP or UDP headers. Application Layer Gateways (ALGs) may inspect traffic based on port numbers, but their behavior can be undocumented or unreliable, including when data spans TCP segments or packets use TCP options.
Many NATs work more reliably with TCP than with UDP, and UDP mapping timers vary. Port assignments can change unpredictably; parallel NATs can also make the observed IP address vary. These differences make it difficult to assume that one workaround will behave consistently across networks.
NAT equipment does not all handle traffic the same way. A method that works on one network may fail on another, or stop working when an address mapping changes.
§4What a Workaround Proposal Must Explain
Because UNSAF methods are short-term fixes, the IAB says every proposal must explicitly address five points:
- Define one precise problem and keep the proposed fix within that scope.
- Describe an exit strategy or transition plan.
- Explain how the approach could make systems more brittle, such as by adding dependencies across network layers.
- Identify requirements for longer-term technical solutions and contribute to finding them.
- Discuss the practical behavior of deployed NATs, supported by experience reports.
The memo warns that generalizing a short-term fix can prolong dependence on it and make it no longer short term.
A proposal must say exactly which problem it addresses, how users can move away from it, and what dependencies or NAT behaviors could cause failures. It must also help identify the needs of a longer-term solution.
- Limited scopeDefine one specific problem.
- Exit strategyExplain how the workaround will be phased out.
- BrittlenessDescribe added dependencies and failure risks.
- Long-term needsIdentify requirements for sound technical solutions.
- NAT experienceDiscuss observed behavior in deployed NATs.
§5Security Considerations and Examples
The security concern is that, without MIDCOM, an UNSAF process cannot make a firewall admit incoming communication under proper supervision. A workaround may therefore circumvent the policy the firewall is meant to enforce, especially if one host acts for several internal machines.
Appendix C illustrates why an address can depend on the observer. In its example, Box B sees Box A at an address and port on 10.1.2.27, while Box C sees an address in 192.168.3.0/24. A second example describes a home network with separate wired and wireless private realms after a NAT-enabled wireless access point is added.
A workaround that opens a path through a NAT may also bypass a firewall rule. The examples show that the same host can appear at different addresses from different parts of a network.