Internet Draft Melinda Shore
draft-shore-nat-reachability-00.txt Cisco Systems
March 2004
Expires September 2004
Establishing Reachability Behind NATs
<draft-shore-nat-reachability-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
Shore [Page 1]
Internet Draft Establishing Reachability March 2004
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
One of the most persistent, difficult problems introduced with NATs
is voluntary reachability -- a NATted device making itself avail-
able to the public internet. This paper is an overview of the cur-
rent status of reachability, a decomposition of the problem and a
proposal for going forward.
1. Introduction
NAT traversal has been recognized for some time to be a significant
problem in environments in which session-oriented protocols, like
SIP and H.323, are used, and in which endpoints wish to be reach-
able despite being NATted. It should be noted that while unreacha-
bility was not an original goal of NAT, NAT is commonly used as a
security mechanism specifically for inhibiting reachability.
This paper argues that the problem of reachability in the presence
of NATs needs to be considered as two distinct problems, and intro-
duces an approach for solving the problem.
2. Core problems
There are two problems to be solved in order to provide reachabil-
ity behind NATs. The first is the problem of obtaining a public
presence, and the second is the problem of advertising that pres-
ence.
2.1. Obtaining a public presence
NAT currently works by implication. A NAT device detects a new
outbound stream and creates a mapping between the internal, private
address and an external, routable address. That is to say that
rather than having an endpoint explicitly ask the NAT for a mapping
to a reachable address, the NAT infers when it should act based on
somewhat crude policy. Over the past several years there has been
growing recognition of a need to make the process of obtaining a
Shore [Page 2]
Internet Draft Establishing Reachability March 2004
public presence explicit. An endpoint or its proxy should be able
to make a direct request for a NAT table mapping and learn the
results (i.e. the external port/address/protocol tuple). This
would have multiple advantages: 1) no more guesswork, 2) explicit
requests would allow for the possibility of "wildcarding," to allow
more than one external host to reach the device behind the NAT, and
3) it would be possible to make additional policy requests, includ-
ing authorization based on authenticated identity and other policy
elements. Several different approaches have been developed, and
these are discussed below.
2.1.1. Discovery
This approach does not make an explicit request directly to the
NAT, but relies on request by implication combined with technology
to discover the external address that the NAT assigned (referred to
in some quarters as "Unilateral Self-Address Fixing," or UNSAF
[RFC3424]). The protocol standardized by the IETF to do self-
address discovery is STUN [RFC3489]. While the protocol is very
useful for common cases encountered in voice over IP applications,
it should be noted that it will not work for TCP or for symmetric
NATs. Whether or not it is useful for establishing reachability is
completely dependent on the type of NAT the endpoint sits behind,
but in the general case it will not be.
2.1.2. Off-path signaling requests
This is the most common request model at the moment, and is essen-
tially modeled on a client-server relationship. An endpoint or its
proxy "knows" the location of a NAT and sends a request for an
address mapping directly to the NAT. While it suffers from a lack
of robustness in the face of topological complexity, it is probably
the best approach to take to establish general reachability. In
the general case, when a device makes itself available to be con-
tacted by another party (say, in a VoIP call or peer-to-peer appli-
cation), it may not know in advance who will be contacting it, or
it may want to be reachable by more than one party or, indeed,
everybody. The preference for off-path signaling in this scenario
is discussed below, in the discussion of on-path signaling.
Examples of off-path NAT request protocols include midcom
[RFC3303], Universal Plug and Play (UPnP), and RSIP [RFC3103]. It
should be mentioned that RSIP is also a relaying protocol (see
below).
Shore [Page 3]
Internet Draft Establishing Reachability March 2004
2.1.3. On-path signaling requests
On-path signaling uses an RSVP-like [RFC2205] approach to locating
and communicating with network devices. A request is sent into the
network, from an endpoint towards another endpoint with which it
wishes to establish connectivity, and network devices along the
path may intercept the request and act on it (or not). Routing is
handled by normal network-layer mechanisms and device location is
implicit in the sending of the request.
While this approach does not have an established track record there
are several projects underway to create new on-path signaling pro-
tocols, and at the moment there is considerable momentum behind it.
The IETF has chartered the NSIS working group [NSIS], and there are
proprietary efforts outside the IETF.
While on-path signaling has several considerable advantages over an
off-path approach, there is one scenario in which it cannot be
used, and that is when the endpoint needs to make a request of a
NAT that is not path-oriented. For example, when placing a tele-
phone call there is a calling party and a called party. In this
case the calling party would send an on-path signaling request
towards the called party, and it would be intercepted and acted
upon by NATs the request traversed en-route. Obviously, this
approach requires a destination address for the request. (If the
request were addressed directly to a NAT, it would become an
instance of off-path signaling).
In situations in which the goal is to establish general reachabil-
ity, the endpoint must communicate directly with the NAT and
request what is essentially a wildcarded address mapping (traffic
from "any" outside address/port pair arriving here would be for-
warded to a single "inside" address/port pair).
2.1.4. Relays
Relays are probably the most common solution to the problem of pro-
viding reachability to NATted devices. There are several products
on the market with specialized support for VoIP, such as the ones
provided by Ridgeway Systems [Ridgeway] and Jasomi Networks
[Jasomi]. These are proprietary technologies.
Relays provide a mechanism for creating reachability by placing a
device on the outside of the NAT and having it forward traffic to
an endhost by encapsulating it or passing it through a pinhole that
was created by having the NATted device initiate an outbound
Shore [Page 4]
Internet Draft Establishing Reachability March 2004
connection to the external relay device.
The only standardized relaying technology designed to provide
reachability for devices behind NATs is Realm-Specific IP (rsip)
[RFC3103]. Unlike the proprietary approaches mentioned above, RSIP
puts the "outside" end of the relay on the NAT device itself.
Traffic is encapsulated and passed to the internal endpoint. There
is also some interest within the IETF in publishing TURN [Rosen-
berg], another relaying protocol.
Relays can work either through explicit requests, as is the case
with RSIP, or through stateful inspection/traffic intercept. The
latter is the more common case, since it does not require the
replacement of network equipment and because major network equip-
ment vendors have been slow to go to this approach. Relays intro-
duce performance problems, both in terms of tandeming and queueing
delay, and in terms of encapsulation overhead. They also provide
the means to skirt network edge security policy, providing only
very crude policy parameters (the address/port pair for the relay)
for allowing or denying traffic.
2.2. Findability
Acquiring a reachable address is not sufficient for becoming reach-
able in practice. Peers need to know what that address is.
Traditionally, the mechanism for contacting specific applications
on specific hosts has relied on the use of static, publicly-
routable IP addresses and the use of "well-known" ports. However,
in the presence of NATs endpoint addresses are no longer publicly
routable, and when NAT workarounds are used to acquire a publicly-
routable address/port tuple, it is almost certainly the case that
the port will not be at the expected well-known location. That is
to say that among the things that NAT breaks is the historic use of
static port locations.
In VoIP and other session-oriented protocols, the address of the
data streams is provided by means of signaling. Endpoints tell
each other explicitly what addresses and ports to use for media
traffic, after having acquired a routable address using one of the
mechanisms described above. The more difficult problem is how to
establish the signaling streams, but it is commonly the case with
these applications that the signaling streams are mediated by a
centralized server, which is already publicly reachable. However,
in a peer-to-peer environment in which signaling is not mediated,
the problems of acquiring a public presence and then advertising
Shore [Page 5]
Internet Draft Establishing Reachability March 2004
that public presence remain.
The Domain Name System (DNS) [RFC1034] is the location service for
the internet. While Dynamic DNS [RFC2136] provides a mechanism for
dynamically updating endpoint addresses assigned by DHCP or other
non-static address assignment mechanisms, it really is not suitable
for per-stream updates, nor is DNS suitable for rapidly-changing
configurations. See [RFC3467] for a detailed discussion of the
role of DNS in a changing internet.
3. Proposal
While DNS is unsuitable as a general-purpose location database, it
can be used as a location service for stable internet services,
including other lookup services. This is accomplished through the
use of SRV records [RFC2782]. For example, a client wishing to
locate an LDAP server for the domain "example.com" would submit a
DNS query for a resource record of type "SRV" with the contents
"_ldap._tcp.example.com". DNS would return a record, if available,
providing the IP address and port number of example.com's LDAP
server.
We are proposing that an endpoint acquire a reachable address for a
particular service (say, SIP signaling) using midcom or a midcom-
like protocol, then register that address with a domain's LDAP
server. An external (to the NAT) peer trying to contact that end-
point would use DNS to locate the domain's LDAP server, then query
the LDAP server for the address and port at which the endpoint is
reachable.
This problem requires the use of an off-path signaling protocol,
since it is not path-oriented. The availability of routable source
and destination addresses is inherent in the notion of a path, and,
by definition of this problem, we do not have one in this case.
This is true even in cases where we wish to be reachable by only
one peer.
While we propose the use of midcom as the off-path signaling proto-
col, it is not the only protocol available. Even a relaying proto-
col could be used to establish an address, although this is not
recommended for security and policy reasons.
Also, we should note that while LDAP is the de facto standard local
directory service for the internet, a database or another local
directory service would serve instead. We are using LDAP for
illustrative purposes.
Shore [Page 6]
Internet Draft Establishing Reachability March 2004
3.1. Reachability information elements
The directory entry consists of
o Address
o Port
o Transport protocol (TCP, UDP, SCTP, etc.)
o "Application" protocol (FTP, SIP, H.323, etc.)
o Name
as follows:
Address:
the reachable, or public address provided by the NAT
Port:
the reachable, or public port provided by the NAT
Transport protocol:
self-evident
Application protocol:
self-evident
Name:
the name being used as the basis for providing reachability,
or as the directory index. The value will depend on the
application. For example, in the case of an FTP or web
server, it may be a hostname. For a VoIP application, it may
be the name or a user, or another identifying string such as a
telephone number. It could also be a HIP host identifier
[Moskowitz].
4. Use scenarios
Shore [Page 7]
Internet Draft Establishing Reachability March 2004
(1) +-------+
------------------>| |
| | NAT |
| --------------| |
| | (2) | |
| V +-------+
+----------+
| Server |
+----------+
| +---------------+
|------------->| LDAP Server |
(3) +---------------+
Figure 1
Figure 1 shows a server behind a NAT acquiring an address from the
NAT and registering it with the LDAP directory server. Message 1
is a request to the NAT for an address mapping. Message 2 is the
reply, and message 3 is a directory update containing the reachable
{address,port,protocol} tuple.
(1)
------------------------------
| |
V |
+------------+ (2) |
| DNS Server |----------- |
+------------+ | +----------+
----->| |
| Client |
-------| |
+-------------+ | (3) +----------+
| LDAP Server |<------ |
+-------------+ |
^ |
| |
-----------------------------
(4)
Figure 2
Figure 2 shows a client finding the address for a server behind a
NAT. It first makes a DNS request for a SRV record for the domain
of interest (message 1) and receives a response in message 2. In
Shore [Page 8]
Internet Draft Establishing Reachability March 2004
message 3 it then contacts the LDAP server at the address returned
by DNS with a query for the address and port information for the
server it is looking for, receiving a request in message 4. It can
then use that information to contact the server.
5. Security considerations
This mechanism introduces several new security exposures that would
not exist if the NATted devices were not, in fact, NATted. First,
the mechanism for acquiring an address may be vulnerable to a vari-
ety of attacks depending on the technology used. Those vulnerabil-
ities are addressed in documents describing those mechanisms and
are out of scope for this document.
There are two processes that are of interest to this document: 1)
registering a reachable address/port tuple with a directory, and 2)
querying the directory to find a reachable address. There are two
clear risks in the registration process. The first is false regis-
tration, or registering an illegitimate address. This attack
allows miscreants to redirect network communication so that, for
example, someone wishing to place a SIP call would receive not the
address of the party they are trying to call, but instead the
address of an attacker, who could then eavesdrop on or even mas-
querade as the called party. The second risk lies in unauthenti-
cated deregistration, which could be used to commit a denial-of-
service attack against a NATted device. In both cases the regis-
tration process requires that the registration/deregistration
request packets be authenticated and integrity protected.
The query process introduces the possibility of an attacker inject-
ing a spoofed response to a query, allowing the same sorts of
attacks as false registration (although it should be noted that DNS
responses are almost never authenticated in actual practice). To
protect against this attack, the responses from the directory must
be authenticated and integrity protected.
6. Infrastructure requirements and transition
As with all NAT workarounds, this proposal introduces additional
network elements, increasing network complexity and operating
costs. In this particular case the new elements are:
o A publicly-accessible LDAP server
o A midcom- (or similar) capable NAT
Shore [Page 9]
Internet Draft Establishing Reachability March 2004
o Appropriate authentication technology
The domain's DNS server will need to provide an SRV RR for the
domain.
Additionally, clients and peers wishing to contact devices behind
NATs will need to know to request addressing information from a
domain's LDAP server, and hosts behind a NAT wishing to be reach-
able will need to be able to acquire a routable address from a NAT
(by supporting midcom, for example) and then register that address
with an LDAP server.
That's a lot to ask, and it's not currently possible to do the sort
of forklift upgrade of the internet, or even of an enterprise or
local service provider network, to make this all work at once.
What can be said about transitioning, however, is that as these
facilities are added incrementally to existing software and exist-
ing operational networks, NATted hosts would be no less reachable
than they are today.
7. Operational issues and reliability
Introducing additional network elements always introduces the like-
lihood of increased instability, and there is a tradeoff against
the gains from increased functionality. While there is great
demand for a mechanism to allow NATted devices to establish reacha-
bility and there is at this time no generalized mechanism (other
than what is being proposed here) for doing so, we think it is
worthwhile to discuss some of the sources of instability being
introduced.
The most obvious problem is that of maintaining consistent state.
The NATted device can crash, the LDAP server can crash, or the NAT
can crash, and any of these events might cause the shared state to
desynchronize.
Of these three events the possibility of the LDAP server crashing
is the least difficult to resynchronize. It may be down when a
client wishes to register its address, or it may be down when a
client wishes to deregister its address. If it is down and
unavailable for registration, the NATted device is effectively
unavailable. If it is down and unavailable for deregistration, the
reachable address may still be found even if the NATted device is
offline or unreachable. Both of these cases may be mitigated
through request retransmission (although the problem remains if the
LDAP server crashes and then the client crashes before a
Shore [Page 10]
Internet Draft Establishing Reachability March 2004
deregistration request is accepted and acted upon; we recommend
timeouts on directory entries for this reason).
If the NATted device crashes it may lose state. In particular, it
may lose information about what addresses it has acquired from the
NAT. There are two possibilities for resynchronizing -- contact
the NAT, or contact the LDAP server. It may be the case that both
are required. The NAT should be contacted to find out what map-
pings are installed, assuming that the address acquisition protocol
permits it. The LDAP server should be contacted to find out what
directory entries have been installed, either to confirm that they
are there or to delete any that are installed if the NAT query
reveals that some or all of them are gone (note that a timeout on
directory entries may be sufficient to take care of this latter
issue).
If the NAT itself crashes it is almost certainly the case that the
requested NAT entries will be lost on reboot. In order to recover,
the device behind the NAT first needs to be able to detect that the
NAT crashed. It then needs to delete the existing directory entry
on the LDAP server, request a new reachable address from the NAT,
and install a new directory entry.
8. Conclusion
One of the most serious problems introduced by NATs is that it ren-
ders NATted devices essentially unreachable, breaking some of the
semantics of IP addressing. There have been several proposals and
work-arounds, but for the most part these have been specialized to
particular applications, unsound from a policy enforcement perspec-
tive, or just generally slap-dash.
Steve Deering once said that the answer to crud in the network is
not more crud in the network. It's hard to argue against that, but
it assumes the possibility of solving the problems introduced by
crud simply removing some of it. In practice, that may not be an
option.
Several different proposals for solving different aspects of NAT-
introduced problems have been put forward. Most of these have been
oriented towards one specific application, voice over IP. That is
not the only application having difficulty with NATs, however, or
with the more general problem of establishing reachability. We
feel that by breaking down the problem into its two component parts
and solving each of those parts using existing technology (say,
midcom and LDAP) we can provide a cleaner and more general approach
Shore [Page 11]
Internet Draft Establishing Reachability March 2004
to solving the reachability problem.
9. References
[Jasomi] "Jasomi Networks Peering Point Solutions"
http://www.jasomi.com/solutions.html
[Jennings] Jennings, Cullen. "NAT Classification Results using STUN,"
work in progress, February 2004. draft-jennings-midcom-stun-
results-00.
[Moskowitz] Moskowitz, R. et al. "Host Identity Protocol," work in
progress, February 2004. draft-moskowitz-hip-09.
[NSIS] "Next Steps in Signaling (nsis)" http://www.ietf.org/html.char-
ters/nsis-charter.html
[RFC1034] Mockapetris, P. "Domain Names -- Concepts and Facilities,"
RFC 1034, November 1987.
[RFC2136] Vixie, P. et al. "Dynamic Updates in the Domain Name System
(DNS UPDATE)," RFC 2136, April 1997.
[RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP) Ð
Version 1 Functional Specification," RFC 2205, September 1997.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov. "A DNS RR for spec-
ifying the location of services (DNS SRV)," RFC 2782, February
2000.
[RFC3103] Borella, M. et al. "Realm Specific IP: Protocol Specifica-
tion," RFC 3103, October 2001.
[RFC3303] Srisuresh, P, et al. "Middlebox communication architecture
and framework," RFC 3303, August 2002.
[RFC3424] Daigle, L., ed. "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation," RFC
3424, November 2002.
[RFC3467] Klensin, J. "Role of the Domain Name System (DNS)," RFC 3467,
February 2003.
[RFC3489] Rosenberg, J. et al. "STUN - Simple Traversal of User Data-
gram Protocol (UDP) Through Network Address Translators (NATs),"
RFC 3489, March 2003.
Shore [Page 12]
Internet Draft Establishing Reachability March 2004
[Ridgeway] "IPFreedom" http://www.ridgewaysystems.com/products.aspx
[Rosenberg] Rosenberg, Jonathan, Mahy, Rohan, and Christian Huitema.
"Traversal Using Relay NAT (TURN)," work in progress, October 2003.
draft-rosenberg- midcom-turn-03.
10. Full copyright statement
Copyright (C) The Internet Society (2004). This document is sub-
ject to the rights, licenses and restrictions contained in BCP 78
and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REP-
RESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
11. Intellectual property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC docu-
ments can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this speci-
fication can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Shore [Page 13]
Internet Draft Establishing Reachability March 2004
Author's address
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, NY 14850
USA
mshore@cisco.com
Shore [Page 14]