Stun协议RFC5389

Network Working Group J. Rosenberg

Request for Comments: 5389 Cisco

Obsoletes: 3489 R. Mahy

Category: Standards Track P. Matthews

Unaffiliated

D. Wing

Cisco

October 2008

Session Traversal Utilities for NAT (STUN)

Abstract

Session Traversal Utilities for NAT (STUN) is a protocol that serves

as a tool for other protocols in dealing with Network Address

Translator (NAT) traversal. It can be used by an endpoint to

determine the IP address and port allocated to it by a NAT. It can

also be used to check connectivity between two endpoints, and as a

keep-alive protocol to maintain NAT bindings. STUN works with many

existing NATs, and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool

to be used in the context of a NAT traversal solution. This is an

3. Overview of Operation ...........................................5

4. Terminology .....................................................8

5. Definitions .....................................................8

6. STUN Message Structure .........................................10

7. Base Protocol Procedures .......................................12

7.1. Forming a Request or an Indication ........................12

7.2. Sending the Request or Indication .........................13

Rosenberg, et al. Standards Track [Page 1]

RFC 5389 STUN October 2008

7.2.1. Sending over UDP ...................................13

7.2.2. Sending over TCP or TLS-over-TCP ...................14

7.3. Receiving a STUN Message ..................................16

7.3.1. Processing a Request ...............................17

7.3.1.1. Forming a Success or Error Response .......18

7.3.1.2. Sending the Success or Error Response .....19

7.3.2. Processing an Indication ...........................19

7.3.3. Processing a Success Response ......................19

7.3.4. Processing an Error Response .......................20

10. Authentication and Message-Integrity Mechanisms ...............22

10.2.3. Receiving a Response ..............................27

12. Backwards Compatibility with RFC 3489 .........................28

12.1. Changes to Client Processing .............................29

12.2. Changes to Server Processing .............................29

13. Basic Server Behavior .........................................30

14. STUN Usages ...................................................30

15. STUN Attributes ...............................................31

15.1. MAPPED-ADDRESS ...........................................32

15.2. XOR-MAPPED-ADDRESS .......................................33

15.3. USERNAME .................................................34

15.4. MESSAGE-INTEGRITY ........................................34

15.7. REALM ....................................................38

15.9. UNKNOWN-ATTRIBUTES .......................................38

15.11. ALTERNATE-SERVER ........................................39

16.1.1. Outside Attacks ...................................39

16.1.2. Inside Attacks ....................................40

16.2. Attacks Affecting the Usage ..............................40

16.2.1. Attack I: Distributed DoS (DDoS) against a

Target ............................................41

16.2.2. Attack II: Silencing a Client .....................41

Rosenberg, et al. Standards Track [Page 2]

RFC 5389 STUN October 2008

16.2.3. Attack III: Assuming the Identity of a Client .....42

16.2.4. Attack IV: Eavesdropping ..........................42

16.3. Hash Agility Plan ........................................42

17. IAB Considerations ............................................42

18. IANA Considerations ...........................................43

18.1. STUN Methods Registry ....................................43

18.2. STUN Attribute Registry ..................................43

18.3. STUN Error Code Registry .................................44

18.4. STUN UDP and TCP Port Numbers ............................45

21. Acknowledgements ..............................................47

Rosenberg, et al. Standards Track [Page 3]

RFC 5389 STUN October 2008

1. Introduction

The protocol defined in this specification, Session Traversal

Utilities for NAT, provides a tool for dealing with NATs. It

provides a means for an endpoint to determine the IP address and port

allocated by a NAT that corresponds to its private IP address and

port. It also provides a way for an endpoint to keep a NAT binding

alive. With some extensions, the protocol can be used to do

connectivity checks between two endpoints [MMUSIC-ICE], or to relay

In keeping with its tool nature, this specification defines an

Establishment (ICE) [MMUSIC-ICE] is one usage of STUN. SIP Outbound

require extensions to STUN. A STUN extension can be in the form of

new methods, attributes, or error response codes. More information

on STUN usages can be found in Section 14.

2. Evolution from RFC 3489

STUN was originally defined in RFC 3489 [RFC3489]. That

specification, sometimes referred to as "classic STUN", represented

itself as a complete solution to the NAT traversal problem. In that

solution, a client would discover whether it was behind a NAT,

and port within the body of protocols, such as the Session Initiation

of RFC 3489 has found that classic STUN simply does not work

learned through classic STUN are sometimes usable for communications

remedy in cases where it did not. Furthermore, classic STUN’s

algorithm for classification of NAT types was found to be faulty, as

many NATs did not fit cleanly into the types defined there.

Rosenberg, et al. Standards Track [Page 4]

RFC 5389 STUN October 2008

Classic STUN also had a security vulnerability -- attackers could

provide the client with incorrect mapped addresses under certain

topologies and constraints, and this was fundamentally not solvable

through any cryptographic means. Though this problem remains with

this specification, those attacks are now mitigated through the use

of more complete solutions that make use of STUN.

For these reasons, this specification obsoletes RFC 3489, and instead

describes STUN as a tool that is utilized as part of a complete NAT

methodology, such as SIP. SIP Outbound [SIP-OUTBOUND] is a complete

magic cookie mechanism for demultiplexing STUN with application

ID defined in RFC 3489, allowing the change to be backwards

compatible. Mapped addresses are encoded using a new exclusive-or

format. There are other, more minor changes. See Section 19 for a

more complete listing.

Due to the change in scope, STUN has also been renamed from "Simple

Traversal of UDP through NAT" to "Session Traversal Utilities for

NAT". The acronym remains STUN, which is all anyone ever remembers

anyway.

This section is descriptive only.

Rosenberg, et al. Standards Track [Page 5]