Network Working Group J. Ronberg
Request for Comments: 3489 J. Weinberger
Category: Standards Track dynamicsoft
C. Huitema
Microsoft
R. Mahy
Cisco
March 2003
STUN - Simple Traversal of Ur Datagram Protocol (UDP)
Through Network Address Translators (NATs)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Plea refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Rerved.
Abstract
Simple Traversal of Ur Datagram Protocol (UDP) Through Network
Address Translators (NATs) (STUN) is a lightweight protocol that
allows applications to discover the prence and types of NATs and
firewalls between them and the public Internet. It also provides the
ability for applications to determine the public Internet Protocol
(IP) address allocated to them by the NAT. STUN works with many
existing NATs, and does not require any special behavior from them.
As a result, it allows a wide variety of applications to work through
existing NAT infrastructure.
Table of Contents
1. Applicability Statement ................................... 3
2. Introduction .............................................. 3
3. Terminology ............................................... 4
4. Definitions ............................................... 5
5. NAT Variations ............................................ 5
6. Overview of Operation ..................................... 6
7. Message Overview .......................................... 8
8. Server Behavior ........................................... 10
8.1 Binding Requests .................................... 10
Ronberg, et al. Standards Track [Page 1]
RFC 3489 STUN March 2003
8.2 Shared Secret Requests .............................. 13
9. Client Behavior ........................................... 14
9.1 Discovery ........................................... 15
9.2 Obtaining a Shared Secret ........................... 15
9.3 Formulating the Bi
nding Request ..................... 17
9.4 Processing Binding Respons ........................ 17
10. U Cas ................................................. 19
10.1 Discovery Process ................................... 19
10.2 Binding Lifetime Discovery .......................... 21
10.3 Binding Acquisition ................................. 23
11. Protocol Details .......................................... 24
11.1 Message Header ...................................... 25
11.2 Message Attributes .................................. 26
11.2.1 MAPPED-ADDRESS .............................. 27
11.2.2 RESPONSE-ADDRESS ............................ 27
11.2.3 CHANGED-ADDRESS ............................. 28
11.2.4 CHANGE-REQUEST .............................. 28
11.2.5 SOURCE-ADDRESS .............................. 28
11.2.6 USERNAME .................................... 28
11.2.7 PASSWORD .................................... 29
11.2.8 MESSAGE-INTEGRITY ........................... 29
11.2.9 ERROR-CODE .................................. 29
11.2.10 UNKNOWN-ATTRIBUTES .......................... 31
11.2.11 REFLECTED-FROM .............................. 31
12. Security Considerations ................................... 31
12.1 Attacks on STUN ..................................... 31
12.1.1 Attack I: DDOS Against a Target ............. 32
12.1.2 Attack II: Silencing a Client ............... 32
12.1.3 Attack III: Assuming the Identity of a Client 32
12.1.4 Attack IV: Eavesdropping .................... 33
12.2 Launching the Attacks ............................... 33
12.2.1 Approach I: Compromi a Legitimate
STUN Server ................................. 33
12.2.2 Approach II: DNS Attacks .................... 34
12.2.3 Approach III: Rogue Router or NAT ........... 34
12.2.4 Approach IV: MITM ........................... 35
12.2.5 Approach V: Respon Injection Plus DoS ..... 35
12.2.6 Approach VI: Duplication .................... 35
12.3 Countermeasures ..................................... 36
12.4 Residual Threats .................................... 37
13. IANA Considerations ....................................... 38
14. IAB Considerations ........................................ 38
14.1 Problem Definition .................................. 38
14.2 Exit Strategy ....................................... 39
14.3 Brittleness Introduced by STUN ...................... 40
14.4
Requirements for a Long Term Solution ............... 42
14.5 Issues with Existing NAPT Boxes ..................... 43
14.6 In Closing .......................................... 43
Ronberg, et al. Standards Track [Page 2]
RFC 3489 STUN March 2003
15. Acknowledgments ........................................... 44
16. Normative References ...................................... 44
17. Informative References .................................... 44
18. Authors' Address ........................................ 46
19. Full 47
1. Applicability Statement
This protocol is not a cure-all for the problems associated with NAT.
It does not enable incoming TCP connections through NAT. It allows
incoming UDP packets through NAT, but only through a subt of
existing NAT types. In particular, STUN does not enable incoming UDP
packets through symmetric NATs (defined below), which are common in
large enterpris. STUN's discovery procedures are bad on
assumptions on NAT treatment of UDP; such assumptions may prove
合肥少儿英语培训班
invalid down the road as new NAT devices are deployed. STUN does not
work when it is ud to obtain an address to communicate with a peer
which happens to be behind the same NAT. STUN does not work when the
STUN rver is not in a common shared address realm. For a more
complete discussion of the limitations of STUN, e Section 14.
2. Introduction
Network Address Translators (NATs), while providing many benefits,
also come with many drawbacks. The most troublesome of tho
drawbacks is the fact that they break many existing IP applications,
and make it difficult to deploy new ones. Guidelines have been
developed [8] that describe how to build "NAT friendly" protocols,
but many protocols simply cannot be constructed according to tho
guidelines. Examples of such protocols include almost all peer-to-
peer protocols, such as multimedia communications, file sharing and
games.
To combat this problem, Application Layer Gateways (ALGs) have been
embedded in NATs. ALGs perform the application layer functions
required for a particular protocol to traver a NAT. Typically,
this involves rewriting application layer messages to contain
translated address, rather than the ones inrted by the nder of
the message. ALGs have rious limitations, including scalability,
reliability, and speed of deploying new applications. To resolve
the problems, the Middlebox Communications (MIDCOM) protocol is
being developed [9]. MIDCOM allows an application entity, such as an
end client or network rver of some sort (like a Session Initiation
Protocol (SIP) proxy [10]) to control a NAT (or firewall), in order八年级上英语单词表
to obtain NAT bindings and open or clo pinholes. In this way, NATs
and applications can be parated once more, eliminating the need for
embedding ALGs in NATs, and resolving the limitations impod by校规校纪
current architectures.
Ronberg, et al. Standards Track [Page 3]
RFC 3489 STUN March 2003
Unfortunately, MIDCOM requires upgrades to existing NAT and
firewalls, in addition to application components. Complete upgrades
of the NAT and firewall products will take a long time, potentially
years. This is due, in part, to the fact that the deployers of NAT
and firewalls are not the same people who are deploying and using
applications. As a result, the incentive to upgrade the devices刘艺彬
will be low in many cas. Consider, for example, an airport
Internet lounge that provides access with a NAT. A ur connecting
to the NATed network may wish to u a peer-to-peer rvice, but
cannot, becau the NAT doesn't support it. Since the administrators
of the lounge are not the ones providing the rvice, they are not
motivated to upgrade their NAT equipment to support it, using either
an ALG, or MIDCOM.
Another problem is that the MIDCOM protocol requires that the agent
controlling the middleboxes know the identity of tho middleboxes,
and have a relationship with them which permits control. In many
configurations, this will not be possible. For example, many cable
access providers u NAT in front of their entire access network.
This NAT could be in addition to a residential NAT purchad and
operated by the end ur. The end ur will probably not have a
control relationship with the NAT in the cable access network, and
may not even know of its existence.
Many existing proprietary protocols, such as tho for online games
(such as the games described in RFC 3027 [11]) and Voice over IP,
泰语学习网have developed tricks that allow them to operate through NATs without
changing tho NATs. This document is an attempt to take some of
tho ideas, and codify them into an interoperable protocol that can
meet the needs of many applications.
The protocol described here, Simple Traversal of UDP Through NAT
(STUN), allows entities behind a NAT to first discover the prence
of a NAT and the type of NAT, and then to learn the address
bindings allocated by the NAT. STUN requires no changes to NATs, and
works with an arbitrary number of NATs in tandem between the
application entity and the public Internet.
3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[1] and indicate requirement levels for compliant STUN
implementations.
Ronberg, et al. Standards Track [Page 4]
RFC 3489 STUN March 2003
4. Definitions
STUN Client: A STUN client (also just referred to as a client)
is an entity that generates STUN requests. A STUN client can
execute on an end system, such as a ur's PC, or can run in a
network element, such as a conferencing rver.
STUN Server: A STUN Server (also just referred to as a rver)
is an entity that receives STUN requests, and nds STUN
respons. STUN rvers are generally attached to the public
Internet.slash>tuxedo
5. NAT Variations
It is assumed that the reader is familiar with NATs. It has been
obrved that NAT treatment of UDP varies among implementations. The
four treatments obrved in implementations are:
Full Cone: A full cone NAT is one where all requests from the
same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can nd a
packet to the internal host, by nding a packet to the mapped
external address.
Restricted Cone: A restricted cone NAT is one where all requests
from the same internal IP address and port are mapped to the same
external IP address and port. Unlike a full cone NAT, an external
host (with IP address X) can nd a packet to the internal host
only if the internal host had previously nt a packet to IP
address X.不锈钢齿轮泵
头等舱英文Port Restricted Cone: A port restricted cone NAT is like a
restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can nd a packet, with source IP
address X and source port P, to the internal host only if the
internal host had previously nt a packet to IP address X and
port P.
Symmetric: A symmetric NAT is one where all requests from the
same internal IP address and port, to a specific destination IP
address and port, are mapped to the same external IP address and
圣诞节英语资料port. If the same host nds a packet with the same source
address and port, but to a different destination, a different
mapping is ud. Furthermore, only the external host that
receives a packet can nd a UDP packet back to the internal host.
Ronberg, et al. Standards Track [Page 5]
RFC 3489 STUN March 2003
Determining the type of NAT is important in many cas. Depending on
what the application wants to do, it may need to take the particular
behavior into account.
6. Overview of Operation
This ction is descriptive only. Normative behavior is described in
Sections 8 and 9.
/-----\
// STUN \\
| Server
