idnits 2.17.1 draft-ietf-behave-rfc3489bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2404. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6638 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2818 (ref. '5') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2617 (ref. '8') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '11') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-06 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '13') (Obsoleted by RFC 5389) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-01 -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '16') (Obsoleted by RFC 4120, RFC 6649) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: August 5, 2006 C. Huitema 5 Microsoft 6 R. Mahy 7 Plantronics 8 D. Wing 9 Cisco Systems 10 February 2006 12 Simple Traversal of UDP Through Network Address Translators (NAT) (STUN) 13 draft-ietf-behave-rfc3489bis-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 5, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol 47 that provides the ability for applications to determine the public IP 48 addresses and ports allocated to them by the NAT and to keep NAT 49 bindings open. These addresses and ports can be placed into protocol 50 payloads where a client needs to provide a publically routable IP 51 address. STUN works with many existing NATs, and does not require 52 any special behavior from them. As a result, it allows a wide 53 variety of applications to work through existing NAT infrastructure. 55 Table of Contents 57 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 62 6. STUN Message Structure . . . . . . . . . . . . . . . . . . . . 9 63 7. STUN Transactions . . . . . . . . . . . . . . . . . . . . . . 11 64 7.1. Request Transaction Reliability . . . . . . . . . . . . . 11 65 8. General Client Behavior . . . . . . . . . . . . . . . . . . . 12 66 8.1. Request Message Types . . . . . . . . . . . . . . . . . . 12 67 8.1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1.2. Obtaining a Shared Secret . . . . . . . . . . . . . . 13 69 8.1.3. Formulating the Request Message . . . . . . . . . . . 14 70 8.1.4. Processing Responses . . . . . . . . . . . . . . . . . 14 71 8.1.5. Using the Mapped Address . . . . . . . . . . . . . . . 15 72 8.2. Indication Message Types . . . . . . . . . . . . . . . . 17 73 8.2.1. Formulating the Indication Message . . . . . . . . . . 17 74 9. General Server Behavior . . . . . . . . . . . . . . . . . . . 17 75 9.1. Request Message Types . . . . . . . . . . . . . . . . . . 17 76 9.1.1. Receive Request Message . . . . . . . . . . . . . . . 17 77 9.1.2. Constructing the Response . . . . . . . . . . . . . . 19 78 9.1.3. Sending the Response . . . . . . . . . . . . . . . . . 19 79 9.2. Indication Message Types . . . . . . . . . . . . . . . . 19 80 10. Short-Term Passwords . . . . . . . . . . . . . . . . . . . . . 19 81 11. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 20 82 11.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 21 83 11.2. RESPONSE-ADDRESS . . . . . . . . . . . . . . . . . . . . 21 84 11.3. CHANGED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 22 85 11.4. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . 22 86 11.5. SOURCE-ADDRESS . . . . . . . . . . . . . . . . . . . . . 23 87 11.6. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 23 88 11.7. PASSWORD . . . . . . . . . . . . . . . . . . . . . . . . 23 89 11.8. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 23 90 11.9. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 24 91 11.10. REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . . 26 92 11.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 26 93 11.12. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 11.13. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 11.14. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 27 96 11.15. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 27 97 11.16. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 11.17. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 28 99 11.18. BINDING-LIFETIME . . . . . . . . . . . . . . . . . . . . 29 100 12. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 12.1. Defined STUN Usages . . . . . . . . . . . . . . . . . . . 29 102 12.2. Binding Discovery . . . . . . . . . . . . . . . . . . . . 29 103 12.2.1. Applicability . . . . . . . . . . . . . . . . . . . . 29 104 12.2.2. Client Discovery of Server . . . . . . . . . . . . . . 30 105 12.2.3. Server Determination of Usage . . . . . . . . . . . . 30 106 12.2.4. New Requests or Indications . . . . . . . . . . . . . 30 107 12.2.5. New Attributes . . . . . . . . . . . . . . . . . . . . 30 108 12.2.6. New Error Response Codes . . . . . . . . . . . . . . . 30 109 12.2.7. Client Procedures . . . . . . . . . . . . . . . . . . 30 110 12.2.8. Server Procedures . . . . . . . . . . . . . . . . . . 30 111 12.2.9. Security Considerations for Binding Discovery . . . . 30 112 12.3. Connectivity Check . . . . . . . . . . . . . . . . . . . 31 113 12.3.1. Applicability . . . . . . . . . . . . . . . . . . . . 31 114 12.3.2. Client Discovery of Server . . . . . . . . . . . . . . 31 115 12.3.3. Server Determination of Usage . . . . . . . . . . . . 31 116 12.3.4. New Requests or Indications . . . . . . . . . . . . . 31 117 12.3.5. New Attributes . . . . . . . . . . . . . . . . . . . . 31 118 12.3.6. New Error Response Codes . . . . . . . . . . . . . . . 31 119 12.3.7. Client Procedures . . . . . . . . . . . . . . . . . . 31 120 12.3.8. Server Procedures . . . . . . . . . . . . . . . . . . 32 121 12.3.9. Security Considerations for Connectivity Check . . . . 32 122 12.4. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 32 123 12.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 32 124 12.4.2. Client Discovery of Server . . . . . . . . . . . . . . 32 125 12.4.3. Server Determination of Usage . . . . . . . . . . . . 32 126 12.4.4. New Requests or Indications . . . . . . . . . . . . . 33 127 12.4.5. New Attributes . . . . . . . . . . . . . . . . . . . . 33 128 12.4.6. New Error Response Codes . . . . . . . . . . . . . . . 33 129 12.4.7. Client Procedures . . . . . . . . . . . . . . . . . . 33 130 12.4.8. Server Procedures . . . . . . . . . . . . . . . . . . 33 131 12.4.9. Security Considerations for NAT Keepalives . . . . . . 33 132 12.5. Short-Term Password . . . . . . . . . . . . . . . . . . . 33 133 12.5.1. Applicability . . . . . . . . . . . . . . . . . . . . 33 134 12.5.2. Client Discovery of Server . . . . . . . . . . . . . . 34 135 12.5.3. Server Determination of Usage . . . . . . . . . . . . 34 136 12.5.4. New Requests or Indications . . . . . . . . . . . . . 34 137 12.5.5. New Attributes . . . . . . . . . . . . . . . . . . . . 35 138 12.5.6. New Error Response Codes . . . . . . . . . . . . . . . 35 139 12.5.7. Client Procedures . . . . . . . . . . . . . . . . . . 35 140 12.5.8. Server Procedures . . . . . . . . . . . . . . . . . . 35 141 12.5.9. Security Considerations for Short-Term Password . . . 35 142 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 143 13.1. Attacks on STUN . . . . . . . . . . . . . . . . . . . . . 36 144 13.1.1. Attack I: DDoS Against a Target . . . . . . . . . . . 36 145 13.1.2. Attack II: Silencing a Client . . . . . . . . . . . . 36 146 13.1.3. Attack III: Assuming the Identity of a Client . . . . 37 147 13.1.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 37 148 13.2. Launching the Attacks . . . . . . . . . . . . . . . . . . 37 149 13.2.1. Approach I: Compromise a Legitimate STUN Server . . . 38 150 13.2.2. Approach II: DNS Attacks . . . . . . . . . . . . . . . 38 151 13.2.3. Approach III: Rogue Router or NAT . . . . . . . . . . 38 152 13.2.4. Approach IV: Man in the Middle . . . . . . . . . . . . 39 153 13.2.5. Approach V: Response Injection Plus DoS . . . . . . . 39 154 13.2.6. Approach VI: Duplication . . . . . . . . . . . . . . . 39 155 13.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 40 156 13.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 42 157 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42 158 14.1. Problem Definition . . . . . . . . . . . . . . . . . . . 42 159 14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 43 160 14.3. Brittleness Introduced by STUN . . . . . . . . . . . . . 43 161 14.4. Requirements for a Long Term Solution . . . . . . . . . . 45 162 14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 46 163 14.6. In Closing . . . . . . . . . . . . . . . . . . . . . . . 46 164 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 165 15.1. STUN Message Type Registry . . . . . . . . . . . . . . . 47 166 15.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 47 167 16. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 48 168 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 169 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 170 18.1. Normative References . . . . . . . . . . . . . . . . . . 49 171 18.2. Informational References . . . . . . . . . . . . . . . . 50 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 173 Intellectual Property and Copyright Statements . . . . . . . . . . 53 175 1. Applicability Statement 177 This protocol is not a cure-all for the problems associated with NAT. 178 It does not enable incoming TCP connections through NAT. It allows 179 incoming UDP packets through NAT, but only through a subset of 180 existing NAT types. In particular, STUN does not enable incoming UDP 181 packets through "symmetric NATs", which is 183 a NAT where all requests from the same internal IP address and 184 port, to a specific destination IP address and port, are mapped to 185 the same external IP address and port. If the same host sends a 186 packet with the same source address and port, but to a different 187 destination, a different mapping is used. Furthermore, only the 188 external host that receives a packet can send a UDP packet back to 189 the internal host. 191 This type of NAT is common in large enterprises. STUN does not work 192 when it is used to obtain an address to communicate with a peer which 193 happens to be behind the same NAT. STUN does not work when the STUN 194 server is not in a common shared address realm. 196 In order to work with such a NAT, a media relay such as TURN [3] is 197 required. All other types of NATs work without a media relay. 199 For a more complete discussion of the limitations of STUN, see 200 Section 14. 202 2. Introduction 204 Network Address Translators (NATs), while providing many benefits, 205 also come with many drawbacks. The most troublesome of those 206 drawbacks is the fact that they break many existing IP applications, 207 and make it difficult to deploy new ones. Guidelines have been 208 developed [17] that describe how to build "NAT friendly" protocols, 209 but many protocols simply cannot be constructed according to those 210 guidelines. Examples of such protocols include almost all peer-to- 211 peer protocols, such as multimedia communications, file sharing and 212 games. 214 To combat this problem, Application Layer Gateways (ALGs) have been 215 embedded in NATs. ALGs perform the application layer functions 216 required for a particular protocol to traverse a NAT. Typically, 217 this involves rewriting application layer messages to contain 218 translated addresses, rather than the ones inserted by the sender of 219 the message. ALGs have serious limitations, including scalability, 220 reliability, and speed of deploying new applications. 222 Many existing proprietary protocols, such as those for online games 223 (such as the games described in RFC3027 [18]) and Voice over IP, have 224 developed tricks that allow them to operate through NATs without 225 changing those NATs and without relying on ALG behavior in the NATs. 226 This document takes some of those ideas and codifies them into an 227 interoperable protocol that can meet the needs of many applications. 229 The protocol described here, Simple Traversal of UDP Through NAT 230 (STUN), provides a toolkit of functions. These functions allow 231 entities behind a NAT to learn the address bindings allocated by the 232 NAT, to keep those bindings open, and communicate with other STUN- 233 aware to validate connecivity. STUN requires no changes to NATs, and 234 works with an arbitrary number of NATs in tandem between the 235 application entity and the public Internet. 237 3. Terminology 239 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 240 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 241 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 242 [1] and indicate requirement levels for compliant STUN 243 implementations. 245 4. Definitions 247 STUN Client 248 A STUN client (also just referred to as a client) is an entity 249 that generates STUN requests. 251 STUN Server 252 A STUN Server (also just referred to as a server) is an entity 253 that receives STUN requests, and sends STUN responses. 255 Transport Address 256 The combination of an IP address and (UDP or TCP) port. 258 Reflexive Transport Address 259 A transport address learned by a client which identifies that 260 client as seen by another host on an IP network, typically a STUN 261 server. When there is an intervening NAT between the client and 262 the other host, the reflexive address represents the binding 263 allocated to the client on the public side of the NAT. Reflexive 264 transport addresses are learned from the mapped address attribute 265 (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) in STUN responses. 267 Mapped Address 268 The source IP address and port of the STUN Binding Request packet 269 received by the STUN server and inserted into the mapped address 270 attribute (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) of the Binding 271 Response message. 273 5. Overview of Operation 275 This section is descriptive only. Normative behavior is described in 276 Section 8 and Section . 278 /----\ 279 // STUN \\ 280 | Server | 281 \\ // 282 \----/ 284 +--------------+ Public Internet 285 ................| NAT 2 |....................... 286 +--------------+ 288 +--------------+ Private NET 2 289 ................| NAT 1 |....................... 290 +--------------+ 292 /----\ 293 // STUN \\ 294 | Client | 295 \\ // Private NET 1 296 \----/ 298 Figure 1: Typical STUN Server Configuration 300 The typical STUN configuration is shown in Figure 1. A STUN client 301 is connected to private network 1. This network connects to private 302 network 2 through NAT 1. Private network 2 connects to the public 303 Internet through NAT 2. The STUN server resides on the public 304 Internet. 306 STUN is a simple client-server protocol. Two types of messages are 307 available -- request/response in which client sends a request to a 308 server, and the server returns a response; and indications which can 309 be initiated by the client or by the server and which do not elicit a 310 response. There are two types of requests defined in this 311 specification - Binding Requests, sent over UDP, and Shared Secret 312 Requests, sent over TLS [6] over TCP. Shared Secret Requests ask the 313 server to return a temporary username and password. This username 314 and password are used in a subsequent Binding Request and Binding 315 Response, for the purposes of authentication and message integrity. 317 Binding requests are used to determine the bindings allocated by 318 NATs. The client sends a Binding Request to the server, over UDP. 319 The server examines the source IP address and port of the request, 320 and copies them into a response that is sent back to the client -- 321 this is the 'mapped address'. There are attributes for providing 322 message integrity and authentication. 324 The STUN client is typically embedded in an application which needs 325 to obtain a public IP address and port that can be used to receive 326 data. For example, it might need to obtain an IP address and port to 327 receive Real Time Transport Protocol (RTP [14]) traffic. When the 328 application starts, the STUN client within the application sends a 329 STUN Shared Secret Request to its server, obtains a username and 330 password, and then sends it a Binding Request. STUN servers can be 331 discovered through DNS SRV records [4], and it is generally assumed 332 that the client is configured with the domain to use to find the STUN 333 server. Generally, this will be the domain of the provider of the 334 service the application is using (such a provider is incented to 335 deploy STUN servers in order to allow its customers to use its 336 application through NAT). Of course, a client can determine the 337 address or domain name of a STUN server through other means. A STUN 338 server can even be embedded within an end system. 340 The STUN Binding Request is used to discover the public IP address 341 and port mappings generated by the NAT. Binding Requests are sent to 342 the STUN server using UDP. When a Binding Request arrives at the 343 STUN server, it may have passed through one or more NATs between the 344 STUN client and the STUN server. As a result, the source address of 345 the request received by the server will be the mapped address created 346 by the NAT closest to the server. The STUN server copies that source 347 IP address and port into a STUN Binding Response, and sends it back 348 to the source IP address and port of the STUN request. Every type of 349 NAT will route that response so that it arrives at the STUN client. 351 When the STUN client receives the STUN Binding Response, it compares 352 the IP address and port in the packet with the local IP address and 353 port it bound to when the request was sent. If these do not match, 354 the STUN client knows is behind one or more NATs. If the STUN server 355 is publicly routable the IP address and port in the STUN Binding 356 Response are also publicly routable, and can be used by any host on 357 the public Internet to send packets to the application that sent the 358 STUN request. An application need only listen on the IP address and 359 port from which the STUN request was sent. Packets sent by a host on 360 the public Internet to the public address and port learned by STUN 361 will be received by the application, so long as conditions permit. 363 The conditions in which these packets will not be received by the 364 client are described in Section 1. 366 It should be noted that the configuration in Figure 1 is not the only 367 permissible configuration. The STUN server can be located anywhere, 368 including within another client. The only requirement is that the 369 STUN server is reachable by the client, and if the client is trying 370 to obtain a publicly routable address, that the server reside on the 371 public Internet. 373 6. STUN Message Structure 375 STUN messages are TLV (type-length-value) encoded using big endian 376 (network ordered) binary. STUN messages are encoded using binary 377 fields. All integer fields are carried in network byte order, that 378 is, most significant byte (octet) first. This byte order is commonly 379 known as big-endian. The transmission order is described in detail 380 in Appendix B of RFC791 [2]. Unless otherwise noted, numeric 381 constants are in decimal (base 10). All STUN messages start with a 382 single STUN header followed by a STUN payload. The payload is a 383 series of STUN attributes, the set of which depends on the message 384 type. The STUN header contains a STUN message type, transaction ID, 385 and length. The length indicates the total length of the STUN 386 payload, not including the 20-byte header. 388 There are two categories of STUN message types: Requests and 389 Indications. 391 Upon receiving a STUN request, a STUN server will send a STUN success 392 response or a STUN error response. All STUN success responses MUST 393 have a type whose value is 0x100 higher than their associated 394 request, and all STUN error responses MUST have a type whose value is 395 0x110 higher than their associated request. Any newly defined STUN 396 message types MUST use message type values 0x100 and 0x110 higher for 397 their success and error responses, respectively. STUN Requests are 398 sent reliably (Section 7.1). The transaction ID is used to correlate 399 requests and responses. 401 An indication message can be sent from the client to the server, or 402 from the server to the client. Indication messages are not sent 403 reliably do not have an associated success response message type or 404 associated error response message type. Indication messages can be 405 sent by the STUN client to the server, or from the STUN server to the 406 client. The transaction ID is used to distinguish indication 407 messages. 409 All STUN messages consist of a 20 byte header: 411 0 1 2 3 412 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |0 0| STUN Message Type | Message Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Magic Cookie | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Transaction ID 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 2: Format of STUN Message Header 427 The most significant two bits of every STUN message are 0b00. This, 428 combined with the magic cookie, aids in differentiating STUN packets 429 from other protocols when STUN is multiplexed with other protocols on 430 the same port. 432 The STUN message types Binding Request, Response, and Error Response 433 are defined in Section 8 and Section 9.1. The Shared Secret Request, 434 Response, and Error Response are described in Section 12.5. Their 435 values are enumerated in Section 15. 437 The message length is the size, in bytes, of the message not 438 including the 20 byte STUN header. 440 The magic cookie is a fixed value, 0x2112A442. In the previous 441 version of this specification [13] this field was part of the 442 transaction ID. This fixed value affords easy identification of a 443 STUN message when STUN is multiplexed with other protocols on the 444 same port, as is done for example in [12] and [15]. The magic cookie 445 additionally indicates the STUN client is compliant with this 446 specification. The magic cookie is present in all STUN messages -- 447 requests, success responses and error responses. 449 The transaction ID is a 96 bit identifier. STUN transactions are 450 identified by their unique 96-bit transaction ID. This transaction 451 ID is chosen by the STUN client and MUST be unique for each new STUN 452 transaction by that STUN client. Any two requests that are not bit- 453 wise identical, and not sent to the same server from the same IP 454 address and port, MUST have a different transaction ID. The 455 transaction ID MUST be uniformly and randomly distributed between 0 456 and 2**96 - 1. The large range is needed because the transaction ID 457 serves as a form of randomization, helping to prevent replays of 458 previously signed responses from the server. 460 After the STUN header are zero or more attributes. Each attribute is 461 TLV encoded, with a 16 bit type, 16 bit length, and variable value: 463 0 1 2 3 464 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type | Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Value .... | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 3: Format of STUN Attributes 473 The attribute types defined in this specification are in Section 11 . 475 7. STUN Transactions 477 STUN clients are allowed to pipeline STUN requests. That is, a STUN 478 client MAY have multiple outstanding STUN requests with different 479 transaction IDs and not wait for completion of a STUN request/ 480 response exchange before sending another STUN request. 482 7.1. Request Transaction Reliability 484 When running STUN over UDP it is possible that the STUN request or 485 its response might be dropped by the network. Reliability of STUN 486 request message types is is accomplished through client 487 retransmissions. Clients SHOULD retransmit the request starting with 488 an interval of 100ms, doubling every retransmit until the interval 489 reaches 1.6 seconds. Retransmissions continue with intervals of 1.6 490 seconds until a response is received, or a total of 9 requests have 491 been sent. If no response is received by 1.6 seconds after the last 492 request has been sent, the client SHOULD consider the transaction to 493 have failed. In other words, requests would be sent at times 0ms, 494 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 495 9500ms, the client considers the transaction to have failed if no 496 response has been received. 498 When running STUN over TCP, TCP is responsible for ensuring delivery. 499 The STUN application SHOULD NOT retransmit STUN requests when running 500 over TCP. 502 For STUN requests, failure occurs if there is a transport failure of 503 some sort (generally, due to fatal ICMP errors in UDP or connection 504 failures in TCP) or if retransmissions of the same STUN Request 505 doesn't elicit a Response. If a failure occurs and the SRV query 506 indicated other STUN servers are available, the client SHOULD create 507 a new request, which is identical to the previous, but has a 508 different transaction ID and MESSAGE INTEGRITY attribute (the HMAC 509 will change because the transaction ID has changed). That request is 510 sent to the next element in the list as specified by RFC2782. 512 The Indication message types are not sent reliably. 514 8. General Client Behavior 516 There are two classes of client behavior -- one for the request 517 message types and another for the indication message types. 519 8.1. Request Message Types 521 This section applies to client behavior for the Request message types 522 -- Binding Request and Shared Secret Request. For Request message 523 types, the client must discover the STUN server's address and port, 524 obtain a shared secret, formulate the Request, transmit the request 525 reliability, process the Binding Response, and use the information in 526 the Response. 528 8.1.1. Discovery 530 Unless stated otherwise by a STUN usage, DNS is used to discover the 531 STUN server following these procedures. 533 The client will be configured with a domain name of the provider of 534 the STUN servers. This domain name is resolved to an IP address and 535 port using the SRV procedures specified in RFC2782 [4]. The 536 mechanism for configuring the STUN client with the domain name to 537 look up is not in scope of this document. 539 The DNS SRV service name is "stun". The protocol is "udp" for 540 sending Binding Requests, or "tcp" for sending Shared Secret 541 Requests. The procedures of RFC 2782 are followed to determine the 542 server to contact. RFC 2782 spells out the details of how a set of 543 SRV records are sorted and then tried. However, RFC2782 only states 544 that the client should "try to connect to the (protocol, address, 545 service)" without giving any details on what happens in the event of 546 failure; those details for STUN are described in Section 8.1.3. 548 The default port for STUN requests is 3478, for both TCP and UDP. 549 Administrators SHOULD use this port in their SRV records, but MAY use 550 others. If no SRV records were found, the client performs an A or 551 AAAA record lookup of the domain name. The result will be a list of 552 IP addresses, each of which can be contacted at the default port. 554 8.1.2. Obtaining a Shared Secret 556 As discussed in Section 13, there are several attacks possible on 557 STUN systems. Many of these attacks are prevented through integrity 558 protection of requests and responses. To provide that integrity, 559 STUN makes use of a shared secret between client and server which is 560 used as the keying material for the MESSAGE-INTEGRITY attribute in 561 STUN messages. STUN allows for the shared secret to be obtained in 562 any way (for example Kerberos [16] or ICE [12]). The shared secret 563 MUST have at least 128 bits of randomness. 565 When a client is needs to send a Request or an Indication, it can do 566 one of three things: 568 1. send the message without MESSAGE-INTEGRITY, if permitted by the 569 STUN usage. 571 2. use a short term credential, as determined by the STUN usage. In 572 this case, the STUN Request or STUN Indication would contain the 573 USERNAME and MESSAGE-INTEGRITY attributes. The message would not 574 contain the NONCE attribute. The key for MESSAGE-INTEGRITY is 575 the password. 577 3. use long term credential, as determined by STUN usage. In this 578 case, the STUN request contains the USERNAME, REALM, and MESSAGE- 579 INTEGRITY attributes. The request does not contain the NONCE 580 attribute. The key for MESSAGE-INTEGRITY is MD5(unq(USERNAME- 581 value) ":" unq(REALM-value) ":" password). 583 Based on the STUN usage, the server does one of four things: 585 1. The server processes the request and generates a response. If 586 the request included the MESSAGE-INTEGRITY attribute, the server 587 would also include MESSAGE-INTEGRITY in its response. 589 2. The server generates an error response indicating that MESSAGE- 590 INTEGRITY with short-term or with long-term credentials are 591 required (error 401). To indicate that short-term credentials 592 are required, the REALM attribute MUST NOT be present in the 593 error response. To indicate short-term credentials are required, 594 the REALM attribute MOST be present in the error response. 596 3. The server generates an error response indicating that a NONCE 597 attribute is required (error 435) or that the supplied NONCE 598 attribute's value is stale (error 437). 600 4. The server generates an error response indicating that the short- 601 term credentials are no longer valid (error 430). The client 602 will have to obtain new short-term credentials appropriate to its 603 STUN usage. 605 In all of the above error responses, the NONCE attribute MAY 606 optionally be included in the error response, in which case the 607 client MUST include that NONCE in the subsequent STUN transaction. 608 The NONCE value is not stored by the STUN client; it is only valid 609 for the subsequent STUN transaction and that transactions 610 retransmissions. 612 STUN messages generated in order to obtain the shared secret are 613 formulated like other messages by following Section 8.1.3. 615 8.1.3. Formulating the Request Message 617 The client follows the syntax rules defined in Section 6 and the 618 transmission rules of Section 7. The message type of the MUST be a 619 request type; "Binding Request" or "Shared Secret Request" are the 620 two defined by this document. 622 The client creates a STUN message following the STUN message 623 structure described in Section 6. The client SHOULD add a MESSAGE- 624 INTEGRITY and USERNAME attribute to the Request message. 626 Once formulated, the client sends the Binding Request. Reliability 627 is accomplished through client retransmissions, following the 628 procedure in Section 7.1. 630 The client MAY send multiple requests on the connection, and it may 631 pipeline requests (that is, it can have multiple requests outstanding 632 at the same time). When using TCP the client SHOULD close the 633 connection as soon as it has received the STUN Response. 635 8.1.4. Processing Responses 637 All responses, whether success responses or error responses, MUST 638 first be authenticated by the client. Authentication is performed by 639 first comparing the Transaction ID of the response to an oustanding 640 request. If there is no match, the client MUST discard the response. 641 Then the client SHOULD check the response for a MESSAGE-INTEGRITY 642 attribute. If not present, and the client placed a MESSAGE-INTEGRITY 643 attribute into the associated request, it MUST discard the response. 644 If MESSAGE-INTEGRITY is present, the client computes the HMAC over 645 the response as described in Section 11.8. The key to use depends on 646 the shared secret mechanism. If the STUN Shared Secret Request was 647 used, the key MUST be same as used to compute the MESSAGE-INTEGRITY 648 attribute in the request. 650 If the computed HMAC matches the one from the response, processing 651 continues. The response can either be a Binding Response or Binding 652 Error Response. 654 If the response is an Error Response, the client checks the response 655 code from the ERROR-CODE attribute of the response. For a 400 656 response code, the client SHOULD display the reason phrase to the 657 user. For a 420 response code, the client SHOULD retry the request, 658 this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES 659 attribute of the response. For a 430 response code, the client 660 SHOULD obtain a new one-time username and password, and retry the 661 Allocate Request with a new transaction. For 401 and 432 response 662 codes, if the client had omitted the USERNAME or MESSAGE-INTEGRITY 663 attribute as indicated by the error, it SHOULD try again with those 664 attributes. A new one-time username and password is needed in that 665 case. For a 431 response code, the client SHOULD alert the user, and 666 MAY try the request again after obtaining a new username and 667 password. For a 300 response code, the client SHOULD attempt a new 668 transaction to the server indicated in the ALTERNATE-SERVER 669 attribute. For a 500 response code, the client MAY wait several 670 seconds and then retry the request with a new username and password. 671 For a 600 response code, client MUST NOT retry the request and SHOULD 672 display the reason phrase to the user. Unknown response codes 673 between 400 and 499 are treated like a 400, unknown response codes 674 between 500 and 599 are treated like a 500, and unknown response 675 codes between 600 and 699 are treated like a 600. Any response 676 between 100 and 299 MUST result in the cessation of request 677 retransmissions, but otherwise is discarded. 679 Binding Responses containing unknown optional attributes (greater 680 than 0x7FFF) MUST be ignored by the STUN client. Binding Responses 681 containing unknown mandatory attributions (less than or equal to 682 0x7FFF) MUST be discarded and considered immediately as a failed 683 transaction. 685 It is also possible for an IPv4 host to receive a XOR-MAPPED-ADDRESS 686 or MAPPED-ADDRESS containing an IPv6 address, or for an IPv6 host to 687 receive a XOR-MAPPED-ADDRESS or MAPPED-ADDRESS containing an IPv4 688 address. Clients MUST be prepared for this case. 690 8.1.5. Using the Mapped Address 692 This section applies to the Binding Response message type. The 693 Binding Response message type always includes either the MAPPED- 694 ADDRESS attribute or the XOR-MAPPED-ADDRESS attribute, depending on 695 the presence of the magic cookie in the corresponding Binding 696 Request. 698 The mapped address present in the binding response can be used by 699 clients to facilitate traversal of NATs for many applications. NAT 700 traversal is problematic for applications which require a client to 701 insert an IP address and port into a message, to which subsequent 702 messages will be delivered by other entities in a network. Normally, 703 the client would insert the IP address and port from a local 704 interface into the message. However, if the client is behind a NAT, 705 this local interface will be a private address. Clients within other 706 address realms will not be able to send messages to that address. 708 An example of a such an application is SIP, which requires a client 709 to include IP address and port information in several places, 710 including the Session Description Protocol (SDP [19]) body carried by 711 SIP. The IP address and port present in the SDP is used for receipt 712 of media. 714 To use STUN as a technique for traversal of SIP and other protocols, 715 when the client wishes to send a protocol message, it figures out the 716 places in the protocol data unit where it is supposed to insert its 717 own IP address along with a port. Instead of directly using a port 718 allocated from a local interface, the client allocates a port from 719 the local interface, and from that port, initiates the STUN 720 procedures described above. The mapped address in the Binding 721 Response (XOR-MAPPED-ADDRESS or MAPPED- ADDRESS) provides the client 722 with an alternative IP address and port which it can then include in 723 the protocol payload. This IP address and port may be within a 724 different address family than the local interfaces used by the 725 client. This is not an error condition. In such a case, the client 726 would use the learned IP address and port as if the client was a host 727 with an interface within that address family. 729 In the case of SIP, to populate the SDP appropriately, a client would 730 generate two STUN Binding Request messages at the time a call is 731 initiated or answered. One is used to obtain the IP address and port 732 for RTP, and the other, for the Real Time Control Protocol 733 (RTCP)[14]. The client might also need to use STUN to obtain IP 734 addresses and ports for usage in other parts of the SIP message. The 735 detailed usage of STUN to facilitate SIP NAT traversal is outside the 736 scope of this specification. 738 As discussed above, the addresses learned by STUN may not be usable 739 with all entities with whom a client might wish to communicate. The 740 way in which this problem is handled depends on the application 741 protocol. The ideal solution is for a protocol to allow a client to 742 include a multiplicity of addresses and ports in the PDU. One of 743 those can be the address and port determined from STUN, and the 744 others can include addresses and ports learned from other techniques. 745 The application protocol would then provide a means for dynamically 746 detecting which one works. An example of such an an approach is 747 Interactive Connectivity Establishment (ICE [12]). 749 8.2. Indication Message Types 751 This section applies to client behavior for the Indication message 752 types. 754 8.2.1. Formulating the Indication Message 756 The client follows the syntax rules defined in Section 6 and the 757 transmission rules of Section 7. The message type MUST be one of the 758 Indication message types; none are defined by this document. 760 The client creates a STUN message following the STUN message 761 structure described in Section 6. The client SHOULD add a MESSAGE- 762 INTEGRITY and USERNAME attribute to the Request message. 764 Once formulated, the client sends the Indication message. Indication 765 message types are not sent reliably, do not elicit a response from 766 the server, and are not retransmitted. 768 The client MAY send multiple indications on the connection, and it 769 may pipeline indication messages. When using TCP the client SHOULD 770 close the TCP connection as soon as it has transmitted the indication 771 message. 773 9. General Server Behavior 775 9.1. Request Message Types 777 The server behavior for receiving request message types is described 778 in this section. 780 9.1.1. Receive Request Message 782 A STUN server MUST be prepared to receive Request and Indication 783 messages on the IP address and UDP or TCP port that will be 784 discovered by the STUN client when the STUN client follows its 785 discovery procedures described in Section 8.1.1. Depending on the 786 usage, the STUN server will listen for incoming UDP STUN messages, 787 incoming TCP STUN messages, or incoming TLS exchanges followed by TCP 788 STUN messages. The usages describe how the STUN server determines 789 the usage. 791 The server checks the request for a MESSAGE-INTEGRITY attribute. If 792 not present, the server generates an error response with an ERROR- 793 CODE attribute and a response code of 401. That error response MUST 794 include a NONCE attribute, containing a nonce that the server wishes 795 the client to reflect back in a subsequent request (and therefore 796 include in the message integrity computation). The error response 797 MUST include a REALM attribute, containing a realm from which the 798 username and password are scoped [8]. 800 If the MESSAGE-INTEGRITY attribute was present, the server checks for 801 the existence of the REALM attribute. If the attribute is not 802 present, the server MUST generate an error response. That error 803 response MUST include an ERROR-CODE attribute with response code of 804 434. That error response MUST also include a NONCE and a REALM 805 attribute. 807 If the REALM attribute was present, the server checks for the 808 existence of the NONCE attribute. If the NONCE attribute is not 809 present, the server MUST generate an error response. That error 810 response MUST include an ERROR-CODE attribute with a response code of 811 435. That error response MUST include a NONCE attribute and a REALM 812 attribute. 814 If the NONCE attribute was present, the server checks for the 815 existence of the USERNAME attribute. If it was not present, the 816 server MUST generate an error response. The error response MUST 817 include an ERROR-CODE attribute with a response code of 432. It MUST 818 include a NONCE attribute and a REALM attribute. 820 If the USERNAME attribute was present, the server computes the HMAC 821 over the request as described in Section 11.8. The key is computed 822 as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" password), where 823 the password is the password associated with the username and realm 824 provided in the request. If the server does not have a record for 825 that username within that realm, the server generates an error 826 response. That error response MUST include an ERROR-CODE attribute 827 with a response code of 436. That error response MUST include a 828 NONCE attribute and a REALM attribute. 830 This format for the key was chosen so as to enable a common 831 authentication database for SIP and STUN, as it is expected that 832 credentials are usually stored in their hashed forms. 834 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 835 attribute in the request, the server MUST generate an error response 836 with an ERROR-CODE attribute with a response code of 431. This 837 response MUST include a NONCE attribute and a REALM attribute. 839 If the computed HMAC doesn't differ from the one in the request, but 840 the nonce is stale, the server MUST generate an error response. That 841 error response MUST include an ERROR-CODE attribute with response 842 code 430. That error response MUST include a NONCE attribute and a 843 REALM attribute. 845 The server MUST check for any mantadory attributes in the request 846 (values less than or equal to 0x7fff) which it does not understand. 847 If it encounters any, the server MUST generate a Binding Error 848 Response, and it MUST include an ERROR-CODE attribute with a 420 849 response code. Any attributes that are known, but are not supposed 850 to be present in a message (MAPPED-ADDRESS in a request, for example) 851 MUST be ignored. 853 9.1.2. Constructing the Response 855 To construct the STUN Response the STUN server follows the message 856 structure described in Section 6. The server then copies the 857 Transaction ID from the Request to the Response. If the STUN 858 response is a success response, the STUN server adds 0x100 to the 859 Message Type; if a failure response the STUN server adds 0x110 to the 860 Message Type. 862 Depending in the Request message type and the message attributes of 863 the request, the response is constructed; see Figure 4. 865 9.1.3. Sending the Response 867 All Response messages are sent to the IP address and port the 868 associated Binding Request came from, and sent from the IP address 869 and port the Binding Request was sent to. 871 9.2. Indication Message Types 873 Indication messages cause the server to change its state. Indication 874 message types to not cause the server to send a response message. 876 Indication message types are defined in other documents, for example 877 in [3]. 879 10. Short-Term Passwords 881 Short-term passwords are useful to provide authentication and 882 integrity protection to STUN Request and STUN Response messages. 883 Short-term passwords are useful when there is no long-term 884 relationship with a STUN server and thus no long-term password is 885 shared between the STUN client and STUN server. Even if there is a 886 long-term password, the issuance of a short-term password is useful 887 to prevent dictionary attacks. 889 Short-term passwords can be used multiple times for as long as a 890 usage allows the same short-term password to be used. The duration 891 of validity is determined by usage. 893 11. STUN Attributes 895 To allow future revisions of this specification to add new attributes 896 if needed, the attribute space is divided into optional and mandatory 897 ones. Attributes with values greater than 0x7fff are optional, which 898 means that the message can be processed by the client or server even 899 though the attribute is not understood. Attributes with values less 900 than or equal to 0x7fff are mandatory to understand, which means that 901 the client or server cannot successfully process the message unless 902 it understands the attribute. 904 In order to align attributes on word boundaries, the length of the 905 all message attributes values MUST be 0 or a multiple of 4 bytes. 906 Extensions to this specification MUST also follow this requirement. 908 The values of the message attributes are enumerated in Section 15. 910 The following figure indicates which attributes are present in which 911 messages. An M indicates that inclusion of the attribute in the 912 message is mandatory, O means its optional, C means it's conditional 913 based on some other aspect of the message, and - means that the 914 attribute is not applicable to that message type. 916 Error 917 Attribute Request Response Response 918 ______________________________________________ 919 MAPPED-ADDRESS - C - 920 USERNAME O - - 921 PASSWORD - - - 922 MESSAGE-INTEGRITY O O O 923 ERROR-CODE - - M 924 ALTERNATE-SERVER - - C 925 REALM C C C 926 NONCE C - C 927 UNKNOWN-ATTRIBUTES - - C 928 XOR-MAPPED-ADDRESS - M - 929 XOR-ONLY O - - 930 SERVER - O O 931 BINDING-LIFETIME - O - 933 Figure 4: Mandatory Attributes and Message Types 935 11.1. MAPPED-ADDRESS 937 The MAPPED-ADDRESS attribute indicates the mapped IP address and 938 port. It consists of an eight bit address family, and a sixteen bit 939 port, followed by a fixed length value representing the IP address. 940 If the address family is IPv4, the address is 32 bits. If the 941 address family is IPv6, the address is 128 bits. 943 For backwards compatibility with RFC3489-compliant STUN clients, if 944 the magic cookie was not present in the associated Binding Request, 945 this attribute MUST be present in the associated response. 947 Discussion: Some NATs rewrite the 32-bit binary payloads 948 containing the NAT's public IP address, such as STUN's MAPPED- 949 ADDRESS attribute. Such behavior interferes with the operation of 950 STUN and also causes failure of STUN's message integrity checking. 952 Presence of the magic cookie in the STUN Request indicates the 953 client is compatible with this specification and is capable of 954 processing XOR-MAPPED-ADDRESS. 956 The format of the MAPPED-ADDRESS attribute is: 958 0 1 2 3 959 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 |x x x x x x x x| Family | Port | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Address (variable) 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Figure 5: Format of MAPPED-ADDRESS attribute 968 The address family can take on the following values: 969 0x01: IPv4 970 0x02: IPv6 972 The port is a network byte ordered representation of the port the 973 Binding Request arrived from. 975 The first 8 bits of the MAPPED-ADDRESS are ignored for the purposes 976 of aligning parameters on natural boundaries. 978 11.2. RESPONSE-ADDRESS 980 The RESPONSE-ADDRESS attribute indicates where the response to a 981 Binding Request should be sent. Its syntax is identical to MAPPED- 982 ADDRESS. 984 This attribute is not used by any STUN usages defined in this 985 document except for backwards compatibility with RFC3489 clients when 986 using the Binding Discovery usage (Section 12.2). Section 12.2.8 987 describes when this attribute must be included in a binding response. 989 Issue: should this attribute be made specific to Binding 990 Discovery or moved to another document entirely. 992 11.3. CHANGED-ADDRESS 994 The CHANGED-ADDRESS attribute indicates the IP address and port where 995 responses would have been sent from if the "change IP" and "change 996 port" flags had been set in the CHANGE-REQUEST attribute of the 997 Binding Request. Its syntax is identical to MAPPED-ADDRESS. 999 This attribute is not used by any STUN usages defined in this 1000 document except for backwards compatibility with RFC3489 clients when 1001 using the Binding Discovery usage (Section 12.2). Section 12.2.8 1002 describes when this attribute must be included in a binding response. 1004 Issue: should this attribute be made specific to Binding 1005 Discovery or moved to another document entirely. 1007 11.4. CHANGE-REQUEST 1009 The CHANGE-REQUEST attribute is used by the client to request that 1010 the server use a different address and/or port when sending the 1011 response. The attribute is 32 bits long, although only two bits (A 1012 and B) are used: 1014 0 1 2 3 1015 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0| 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 The meaning of the flags are: 1022 A: This is the "change IP" flag. If true, it requests the server to 1023 send the Binding Response with a different IP address than the one 1024 the Binding Request was received on. 1026 B: This is the "change port" flag. If true, it requests the server 1027 to send the Binding Response with a different port than the one 1028 the Binding Request was received on. 1030 This attribute is not used by any STUN usages defined in this 1031 document. 1033 Issue: should this attribute be made specific to Binding 1034 Discovery or moved to another document entirely. 1036 11.5. SOURCE-ADDRESS 1038 The SOURCE-ADDRESS attribute is present in Binding Responses. It 1039 indicates the source IP address and port that the server is sending 1040 the response from. Its syntax is identical to that of MAPPED- 1041 ADDRESS. 1043 This attribute is not used by any STUN usages defined in this 1044 document except for backwards compatibility with RFC3489 clients when 1045 using the Binding Discovery usage (Section 12.2). Section 12.2.8 1046 describes when this attribute must be included in a binding response. 1048 Issue: should this attribute be made specific to Binding 1049 Discovery or moved to another document entirely. 1051 11.6. USERNAME 1053 The USERNAME attribute is used for message integrity. It identifies 1054 the shared secret used in the message integrity check. The USERNAME 1055 is always present in a Shared Secret Response, along with the 1056 PASSWORD. When message integrity is used with Binding Request 1057 messages, the USERNAME attribute MUST be included. 1059 The value of USERNAME is a variable length opaque value. 1061 11.7. PASSWORD 1063 If the message type is Shared Secret Response it MUST include the 1064 PASSWORD attribute. 1066 The value of PASSWORD is a variable length opaque value. The 1067 password returned in the Shared Secret Response is used as the HMAC 1068 in the MESSAGE-INTEGRITY attribute of a subsequent STUN transaction. 1070 11.8. MESSAGE-INTEGRITY 1072 The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [9] of the STUN 1073 message. The MESSAGE-INTEGRITY attribute can be present in any STUN 1074 message type. Since it uses the SHA1 hash, the HMAC will be 20 1075 bytes. The text used as input to HMAC is the STUN message, including 1076 the header, up to and including the attribute preceding the MESSAGE- 1077 INTEGRITY attribute. That text is then padded with zeroes so as to 1078 be a multiple of 64 bytes. As a result, the MESSAGE-INTEGRITY 1079 attribute is the last attribute in any STUN message. However, STUN 1080 clients MUST be able to successfully parse and process STUN messages 1081 which have additional attributes after the MESSAGE-INTEGRITY 1082 attribute. STUN clients that are compliant with this specification 1083 SHOULD ignore attributes that are after the MESSAGE-INTEGRITY 1084 attribute. 1086 The key used as input to HMAC depends on the STUN usage and the 1087 shared secret mechanism. 1089 11.9. ERROR-CODE 1091 The ERROR-CODE attribute is present in the Binding Error Response and 1092 Shared Secret Error Response. It is a numeric value in the range of 1093 100 to 699 plus a textual reason phrase encoded in UTF-8, and is 1094 consistent in its code assignments and semantics with SIP [10] and 1095 HTTP [11]. The reason phrase is meant for user consumption, and can 1096 be anything appropriate for the response code. The length of the 1097 reason phrase MUST be a multiple of 4 (measured in bytes), 1098 accomplished by added spaces to the end of the text, if necessary. 1099 Recommended reason phrases for the defined response codes are 1100 presented below. 1102 To facilitate processing, the class of the error code (the hundreds 1103 digit) is encoded separately from the rest of the code. 1105 0 1 2 3 1106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | 0 |Class| Number | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Reason Phrase (variable) .. 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 The class represents the hundreds digit of the response code. The 1114 value MUST be between 1 and 6. The number represents the response 1115 code modulo 100, and its value MUST be between 0 and 99. 1117 The following response codes, along with their recommended reason 1118 phrases (in brackets) are defined at this time: 1120 300 (Try Alternate): The client should contact an alternate server 1121 for this request. 1123 400 (Bad Request): The request was malformed. The client should 1124 not retry the request without modification from the previous 1125 attempt. 1127 401 (Unauthorized): The Binding Request did not contain a MESSAGE- 1128 INTEGRITY attribute. 1130 420 (Unknown Attribute): The server did not understand a mandatory 1131 attribute in the request. 1133 430 (Stale Credentials): The Binding Request did contain a MESSAGE- 1134 INTEGRITY attribute, but it used a shared secret that has 1135 expired. The client should obtain a new shared secret and try 1136 again. 1138 431 (Integrity Check Failure): The Binding Request contained a 1139 MESSAGE-INTEGRITY attribute, but the HMAC failed verification. 1140 This could be a sign of a potential attack, or client 1141 implementation error. 1143 432 (Missing Username): The Binding Request contained a MESSAGE- 1144 INTEGRITY attribute, but not a USERNAME attribute. Both 1145 USERNAME and MESSAGE-INTEGRITY must be present for integrity 1146 checks. 1148 433 (Use TLS): The Shared Secret request has to be sent over TLS, 1149 but was not received over TLS. 1151 434 (Missing Realm): The REALM attribute was not present in the 1152 request. 1154 435 (Missing Nonce): The NONCE attribute was not present in the 1155 request. 1157 436 (Unknown Username): The USERNAME supplied in the Request is not 1158 known or is not known in the given REALM. 1160 437 (Stale Nonce): The NONCE attribute was present in the request 1161 but wasn't valid. 1163 500 (Server Error): The server has suffered a temporary error. The 1164 client should try again. 1166 600 (Global Failure): The server is refusing to fulfill the 1167 request. The client should not retry. 1169 Issue: Do 300/500/600 mean that other STUN servers returned in 1170 the same SRV lookup should be retried / not retried? With same 1171 SRV Priority? 1173 11.10. REFLECTED-FROM 1175 The REFLECTED-FROM attribute is present only in Binding Responses, 1176 when the Binding Request contained a RESPONSE-ADDRESS attribute. The 1177 attribute contains the identity (in terms of IP address) of the 1178 source where the request came from. Its purpose is to provide 1179 traceability, so that a STUN server cannot be used as a reflector for 1180 denial-of-service attacks. Its syntax is identical to the MAPPED- 1181 ADDRESS attribute. 1183 This attribute is not used by any STUN usages defined in this 1184 document. 1186 Issue: should this attribute be made specific to Binding 1187 Discovery or moved to another document entirely. 1189 11.11. ALTERNATE-SERVER 1191 The alternate server represents an alternate IP address and port for 1192 a different TURN server to try. It is encoded in the same way as 1193 MAPPED-ADDRESS. 1195 11.12. REALM 1197 The REALM attribute is present in Requests and Responses. It 1198 contains text which meets the grammar for "realm" as described in 1199 RFC3261 [10], and will thus contain a quoted string (including the 1200 quotes). 1202 Presence of the REALM attribute indicates that long-term credentials 1203 are used for the values of the USERNAME, PASSWORD, and MESSAGE- 1204 INTEGRITY attributes. 1206 11.13. NONCE 1208 The NONCE attribute is present in Requests and in Error responses. 1209 It contains a sequence of qdtext or quoted-pair, which are defined in 1210 RFC3261 [10]. 1212 11.14. UNKNOWN-ATTRIBUTES 1214 The UNKNOWN-ATTRIBUTES attribute is present only in a Binding Error 1215 Response or Shared Secret Error Response when the response code in 1216 the ERROR-CODE attribute is 420. 1218 The attribute contains a list of 16 bit values, each of which 1219 represents an attribute type that was not understood by the server. 1220 If the number of unknown attributes is an odd number, one of the 1221 attributes MUST be repeated in the list, so that the total length of 1222 the list is a multiple of 4 bytes. 1224 0 1 2 3 1225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Attribute 1 Type | Attribute 2 Type | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Attribute 3 Type | Attribute 4 Type ... 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 Figure 9: Format of UNKNOWN-ATTRIBUTES attribute 1234 11.15. XOR-MAPPED-ADDRESS 1236 The XOR-MAPPED-ADDRESS attribute is only present in Binding 1237 Responses. It provides the same information that would present in 1238 the MAPPED-ADDRESS attribute but because the NAT's public IP address 1239 is obfuscated through the XOR function, STUN messages are able to 1240 pass through NATs which would otherwise interfere with STUN. See the 1241 discussion in Section 11.1. 1243 This attribute MUST always be present in a Binding Response. 1245 Note: Version -02 of this Internet Draft used 0x8020 for this 1246 attribute, which was in the Optional range of attributes. This 1247 attribute has been moved back to 0x0020 as a Mandatory attribute. 1248 [This paragraph should be removed prior to publication as an RFC.] 1250 The format of the XOR-MAPPED-ADDRESS is: 1252 0 1 2 3 1253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 |x x x x x x x x| Family | X-Port | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | X-Address (Variable) 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Figure 10: Format of XOR-MAPPED-ADDRESS Attribute 1262 The Family represents the IP address family, and is encoded 1263 identically to the Family in MAPPED-ADDRESS. 1265 X-Port is the mapped port, exclusive or'd with most significant 16 1266 bits of the magic cookie. If the IP address family is IPv4, 1267 X-Address is mapped IP address exclusive or'd with the magic cookie. 1268 If the IP address family is IPv6, the X-Address is the mapped IP 1269 address exclusively or'ed with the magic cookie and the 96-bit 1270 transaction ID. 1272 Issue: The motivation for XORing the IP address is clear. Is 1273 there a motivation for XORing the port? 1275 For example, using the "^" character to indicate exclusive or, if the 1276 IP address is 192.168.1.1 (0xc0a80101) and the port is 5555 (0x15B3), 1277 the X-Port would be 0x15B3 ^ 0x2112 = 0x34A1, and the X-Address would 1278 be 0xc0a80101 ^ 0x2112A442 = 0xe1baa543. 1280 11.16. SERVER 1282 The server attribute contains a textual description of the software 1283 being used by the server, including manufacturer and version number. 1284 The attribute has no impact on operation of the protocol, and serves 1285 only as a tool for diagnostic and debugging purposes. The length of 1286 the server attribute MUST be a multiple of 4 (measured in bytes), 1287 accomplished by added spaces to the end of the text, if necessary. 1288 The value of SERVER is variable length. 1290 11.17. ALTERNATE-SERVER 1292 The alternate server represents an alternate IP address and port for 1293 a different STUN server to try. It is encoded in the same way as 1294 MAPPED-ADDRESS. 1296 This attribute is MUST only appear in an Error Response. This 1297 attribute MUST only appear when using the TURN usage. 1299 11.18. BINDING-LIFETIME 1301 The binding lifetime indicates the number of seconds the NAT binding 1302 will be valid. This attribute MUST only be present in Response 1303 messages. This attribute MUST NOT be present unless the STUN server 1304 is aware of the minimum binding lifetime of all NATs on the path 1305 between the STUN client and the STUN server. 1307 12. STUN Usages 1309 STUN is a simple request/response protocol that provides a useful 1310 capability in several situations. In this section, different usages 1311 of STUN are described. Each usages may differ in how STUN servers 1312 are discovered, the message types, and the message attributes that 1313 are supported. 1315 This specification defines the STUN usages for binding discovery 1316 (Section 12.2), connectivity check (Section 12.3), NAT keepalives 1317 (Section 12.4) and short-term password (Section 12.5). 1319 New STUN usages may be defined by other standards-track documents. 1320 New STUN usages MUST describe their applicability, client discovery 1321 of the STUN server, how the server determines the usage, new message 1322 types (requests or indications), new message attributes, new error 1323 response codes, and new client and server procedures. 1325 12.1. Defined STUN Usages 1327 12.2. Binding Discovery 1329 The previous version of this specification, RFC3489 [13], described 1330 only this binding discovery usage. 1332 12.2.1. Applicability 1334 Binding discovery is useful to learn reflexive addresses from servers 1335 on the network. That is, it is used to determine your dynamically- 1336 bound 'public' IP address and UDP port that is assigned by a NAT 1337 between a STUN client and a STUN server. This usage is used with ICE 1338 [12]. 1340 When short-term passwords are used with binding discovery, the 1341 username and password are valid for subsequent transactions for nine 1342 (9) minutes. 1344 12.2.2. Client Discovery of Server 1346 The general client discovery of server behavior is sufficient for 1347 this usage. 1349 12.2.3. Server Determination of Usage 1351 The general binding server behavior is sufficient for this usage. 1353 12.2.4. New Requests or Indications 1355 This usage does not define any new message types. 1357 12.2.5. New Attributes 1359 This usage does not define any new message attributes. 1361 12.2.6. New Error Response Codes 1363 This usage does not define any new error response codes. 1365 12.2.7. Client Procedures 1367 This usage does not define any new client procedures. 1369 12.2.8. Server Procedures 1371 In this usage, the short-term password is valid for 30 seconds after 1372 its initial assignment. 1374 For backwards compatibility with RFC3489-compliant STUN servers, if 1375 the STUN server receives a Binding request without the magic cookie, 1376 the STUN server MUST include the following attributes in the Binding 1377 response; otherwise these attribute MUST NOT be included: 1378 MAPPED-ADDRESS 1379 SOURCE-ADDRESS 1381 Likewise if the STUN server receives a Binding Request containing the 1382 CHANGE-REQUEST attribute without the magic cookie, the STUN server 1383 MUST include the CHANGED-ADDRESS attribute in its Binding Response. 1385 12.2.9. Security Considerations for Binding Discovery 1387 Issue: Currently, the security considerations applies to all the 1388 various usages. Split it up to talk about each one? Create 1389 subsections talking about each usage? 1391 12.3. Connectivity Check 1393 12.3.1. Applicability 1395 This STUN usage primarily provides a connectivity check to a peer 1396 discovered through rendezvous protocols and additionally allows 1397 learning reflexive address discovery to the peer. 1399 The username and password exchanged in the rendezvous protocol is 1400 valid for the duration of the connection being checked. 1402 12.3.2. Client Discovery of Server 1404 The client does not follow the general procedure in Section 8.1.1. 1405 Instead, the client discovers the STUN server's IP address and port 1406 through a rendezvous protocol such as Session Description Protocol 1407 (SDP [19]). An example of such a discovery technique is ICE [12]. 1409 12.3.3. Server Determination of Usage 1411 The server is aware of this usage because it signalsed this port 1412 through the rendezvous protocol. 1414 When operating in this usage, the STUN server is listening on an 1415 ephemeral port rather than the IANA-assigned STUN port. The server 1416 is typically multiplexing two protocols on this port, one protocol is 1417 STUN and the other protocol is the peer-to-peer protocol using that 1418 same port. When used with ICE, the two protocols multiplexed on the 1419 same port are STUN and RTP [14]. 1421 12.3.4. New Requests or Indications 1423 This usage does not define any new message types. 1425 12.3.5. New Attributes 1427 This usage does not define any new message attributes. 1429 12.3.6. New Error Response Codes 1431 This usage does not define any new error response codes. 1433 12.3.7. Client Procedures 1435 This usage does not define any new client procedures. 1437 12.3.8. Server Procedures 1439 In this usage, the short-term password is valid as long as the UDP 1440 port is listening for STUN packets. For example when used with ICE, 1441 the short-term password would be valid as long as the RTP session 1442 (which multiplexes STUN and RTP) is active. 1444 12.3.9. Security Considerations for Connectivity Check 1446 The username and password, which are used for STUN's message 1447 integrity, are exchanged in the rendezvous protocol. Failure to 1448 encrypt and integrity protect the rendezvous protocol is equivalent 1449 in risk to using STUN without message integrity. 1451 12.4. NAT Keepalives 1453 12.4.1. Applicability 1455 This usage is useful in two cases: keeping a NAT binding open in a 1456 client connection to a server and detecting server failure and NAT 1457 reboots. 1459 The username and password used for STUN integrity can be used for 24 1460 hours. 1462 Issue: do we need message integrity for keepalives when doing 1463 STUN and SIP on the same port? Do we need message integrity for 1464 keepalives when doing STUN and RTP on the same port (recvonly, 1465 inactive) 1467 If yes, do we continue using same STUN username/password forever 1468 (days?) 1470 12.4.2. Client Discovery of Server 1472 In this usage, the STUN server and the application protocol are using 1473 the same fixed port. While the multiplexing of two applications on 1474 the same port is similar to the connectivity check (Section 12.3) 1475 usage, this usage is differs as the server's port is fixed and the 1476 server's port isn't communicated using a rendezvous protocol. 1478 12.4.3. Server Determination of Usage 1480 The server multiplexes both STUN and its application protocol on the 1481 same port. The server knows it is has this usage because the URI 1482 that gets resolved to this port indicates the server supports this 1483 multiplexing. 1485 12.4.4. New Requests or Indications 1487 This usage does not define any new message types. 1489 12.4.5. New Attributes 1491 This usage does not define any new message attributes. 1493 12.4.6. New Error Response Codes 1495 This usage does not define any new error response codes. 1497 12.4.7. Client Procedures 1499 If the STUN Response indicates the client's mapped address has 1500 changed from the client's expected mapped address, the client SHOULD 1501 inform other applications of its new mapped address. For example, a 1502 SIP client should send a new registration message indicating the new 1503 mapped address. 1505 12.4.8. Server Procedures 1507 In this usage no authentication is used so there is no duration of 1508 the short-term password. 1510 12.4.9. Security Considerations for NAT Keepalives 1512 Issue: Currently, the security considerations applies to all the 1513 various usages. Split it up to talk about each one? Create 1514 subsections talking about each usage? 1516 12.5. Short-Term Password 1518 In order to ensure interoperability, this usage describes a TLS-based 1519 mechanism to obtain a short-term username and short-term password. 1521 12.5.1. Applicability 1523 To thwart some on-path attacks described in Section 13, it is 1524 necessary for the STUN client and STUN server to integrity protect 1525 the information they exchange over UDP. In the absence of a long- 1526 term secret (password) that is shared between them, a short-term 1527 password can be obtained using the usage described in this section. 1529 The username and password returned in the STUN Shared Secret Response 1530 are valid for use in subsequent STUN transactions for nine (9) 1531 minutes with any hosts that have the same SRV Priority value as 1532 discovered via Section 12.5.2. The username and password obtained 1533 with this usage are used as the USERNAME and as the HMAC for the 1534 MESSAGE-ID in a subsequent STUN message, respectively. 1536 The duration of validity of the username and password obtained via 1537 this usage depends on the usage of the subsequent STUN messages that 1538 are protected with that username and password. 1540 12.5.2. Client Discovery of Server 1542 The client follows the procedures in Section 8.1.1, except the SRV 1543 protocol is TCP rather than UDP and the service name "stun-tls". 1545 For example a client would look up "_stun-tls._tcp.example.com" in 1546 DNS. 1548 12.5.3. Server Determination of Usage 1550 The server advertises this port in the DNS as capable of receiving 1551 TLS-protected STUN messages for this usage. The server MAY also 1552 advertise this same port in DNS for other TCP usages if the server is 1553 capable of multiplexing those different usages. For example, the 1554 server could advertise 1556 12.5.4. New Requests or Indications 1558 The message type Shared Secret Request and its associated Shared 1559 Secret Response and Shared Secret Error Response are defined in this 1560 section. Their values are enumerated in Section 15. 1562 The following figure indicates which attributes are present in the 1563 Shared Secret Request, Response, and Error Response. An M indicates 1564 that inclusion of the attribute in the message is mandatory, O means 1565 its optional, C means it's conditional based on some other aspect of 1566 the message, and N/A means that the attribute is not applicable to 1567 that message type. Attributes not listed are not applicable to 1568 Shared Secret Request, Response, or Error Response. 1570 Shared Shared Shared 1571 Secret Secret Secret 1572 Attribute Request Response Error 1573 Response 1574 ____________________________________________________________________ 1575 USERNAME - M - 1576 PASSWORD - M - 1577 ERROR-CODE - - M 1578 UNKNOWN-ATTRIBUTES - - C 1579 SERVER - O O 1580 REALM C - C 1582 Note: As this usage requires running over TLS, MESSAGE-INTEGRITY 1583 isn't necessary. 1585 12.5.5. New Attributes 1587 No new attributes are defined by this usage. 1589 12.5.6. New Error Response Codes 1591 This usage does not define any new error response codes. 1593 12.5.7. Client Procedures 1595 The client opens up the connection to that address and port, and 1596 immediately begins TLS negotiation[6]. The client MUST verify the 1597 identity of the server. To do that, it follows the identification 1598 procedures defined in Section 3.1 of RFC2818 [5]. Those procedures 1599 assume the client is dereferencing a URI. For purposes of usage with 1600 this specification, the client treats the domain name or IP address 1601 used in Section 9.1 as the host portion of the URI that has been 1602 dereferenced. Once the connection is opened, the client sends a 1603 Shared Secret request. This request has no attributes, just the 1604 header. The transaction ID in the header MUST meet the requirements 1605 outlined for the transaction ID in a binding request, described in 1606 Section 9.3 below. 1608 If the response was a Shared Secret Error Response, the client checks 1609 the response code in the ERROR-CODE attribute. If the response was a 1610 Shared Secret Response, it will contain a short lived username and 1611 password, encoded in the USERNAME and PASSWORD attributes, 1612 respectively. 1614 12.5.8. Server Procedures 1616 After a client has established a TLS session, the server should 1617 expect a STUN message containing a Shared Secret Request. The server 1618 will generates a response, which can either be a Shared Secret 1619 Response or a Shared Secret Error Response. 1621 12.5.9. Security Considerations for Short-Term Password 1623 Issue: Currently, the security considerations applies to all the 1624 various usages. Split it up to talk about each one? Create 1625 subsections talking about each usage? 1627 13. Security Considerations 1629 Issue: This section has not been revised to properly consider the 1630 attacks on each of STUN's different usages. This needs to be done. 1632 13.1. Attacks on STUN 1634 Generally speaking, attacks on STUN can be classified into denial of 1635 service attacks and eavesdropping attacks. Denial of service attacks 1636 can be launched against a STUN server itself, or against other 1637 elements using the STUN protocol. STUN servers create state through 1638 the Shared Secret Request mechanism. To prevent being swamped with 1639 traffic, a STUN server SHOULD limit the number of simultaneous TLS 1640 connections it will hold open by dropping an existing connection when 1641 a new connection request arrives (based on an Least Recently Used 1642 (LRU) policy, for example). Similarly, if the server is storing 1643 short-term passwords it SHOULD limit the number of shared secrets it 1644 will store. The attacks of greater interest are those in which the 1645 STUN server and client are used to launch denial of service (DoS) 1646 attacks against other entities, including the client itself. Many of 1647 the attacks require the attacker to generate a response to a 1648 legitimate STUN request, in order to provide the client with a faked 1649 XOR-MAPPED-ADDRESS or MAPPED-ADDRESS. In the sections below, we 1650 refer to either the XOR-MAPPED-ADDRESS or MAPPED-ADDRESS as just the 1651 mapped address (note the lower case). The attacks that can be 1652 launched using such a technique include: 1654 13.1.1. Attack I: DDoS Against a Target 1656 In this case, the attacker provides a large number of clients with 1657 the same faked mapped address that points to the intended target. 1658 This will trick all the STUN clients into thinking that their 1659 addresses are equal to that of the target. The clients then hand out 1660 that address in order to receive traffic on it (for example, in SIP 1661 or H.323 messages). However, all of that traffic becomes focused at 1662 the intended target. The attack can provide substantial 1663 amplification, especially when used with clients that are using STUN 1664 to enable multimedia applications. 1666 13.1.2. Attack II: Silencing a Client 1668 In this attack, the attacker seeks to deny a client access to 1669 services enabled by STUN (for example, a client using STUN to enable 1670 SIP-based multimedia traffic). To do that, the attacker provides 1671 that client with a faked mapped address. The mapped address it 1672 provides is an IP address that routes to nowhere. As a result, the 1673 client won't receive any of the packets it expects to receive when it 1674 hands out the mapped address. This exploitation is not very 1675 interesting for the attacker. It impacts a single client, which is 1676 frequently not the desired target. Moreover, any attacker that can 1677 mount the attack could also deny service to the client by other 1678 means, such as preventing the client from receiving any response from 1679 the STUN server, or even a DHCP server. 1681 13.1.3. Attack III: Assuming the Identity of a Client 1683 This attack is similar to attack II. However, the faked mapped 1684 address points to the attacker themself. This allows the attacker to 1685 receive traffic which was destined for the client. 1687 13.1.4. Attack IV: Eavesdropping 1689 In this attack, the attacker forces the client to use a mapped 1690 address that routes to itself. It then forwards any packets it 1691 receives to the client. This attack would allow the attacker to 1692 observe all packets sent to the client. However, in order to launch 1693 the attack, the attacker must have already been able to observe 1694 packets from the client to the STUN server. In most cases (such as 1695 when the attack is launched from an access network), this means that 1696 the attacker could already observe packets sent to the client. This 1697 attack is, as a result, only useful for observing traffic by 1698 attackers on the path from the client to the STUN server, but not 1699 generally on the path of packets being routed towards the client. 1701 13.2. Launching the Attacks 1703 It is important to note that attacks of this nature (injecting 1704 responses with fake mapped addresses) require that the attacker be 1705 capable of eavesdropping requests sent from the client to the server 1706 (or to act as a man in the middle for such attacks). This is because 1707 STUN requests contain a transaction identifier, selected by the 1708 client, which is random with 96 bits of entropy. The server echoes 1709 this value in the response, and the client ignores any responses that 1710 don't have a matching transaction ID. Therefore, in order for an 1711 attacker to provide a faked response that is accepted by the client, 1712 the attacker needs to know the transaction ID of the request. The 1713 large amount of randomness, combined with the need to know when the 1714 client sends a request and the IP address and UDP ports used for that 1715 request, precludes attacks that involve guessing the transaction ID. 1717 Since all of the above attacks rely on this one primitive - injecting 1718 a response with a faked mapped address - preventing the attacks is 1719 accomplished by preventing this one operation. To prevent it, we 1720 need to consider the various ways in which it can be accomplished. 1721 There are several: 1723 13.2.1. Approach I: Compromise a Legitimate STUN Server 1725 In this attack, the attacker compromises a legitimate STUN server 1726 through a virus or Trojan horse. Presumably, this would allow the 1727 attacker to take over the STUN server, and control the types of 1728 responses it generates. Compromise of a STUN server can also lead to 1729 discovery of open ports. Knowledge of an open port creates an 1730 opportunity for DoS attacks on those ports (or DDoS attacks if the 1731 traversed NAT is a full cone NAT). Discovering open ports is already 1732 fairly trivial using port probing, so this does not represent a major 1733 threat. 1735 13.2.2. Approach II: DNS Attacks 1737 STUN servers are discovered using DNS SRV records. If an attacker 1738 can compromise the DNS, it can inject fake records which map a domain 1739 name to the IP address of a STUN server run by the attacker. This 1740 will allow it to inject fake responses to launch any of the attacks 1741 above. 1743 13.2.3. Approach III: Rogue Router or NAT 1745 Rather than compromise the STUN server, an attacker can cause a STUN 1746 server to generate responses with the wrong mapped address by 1747 compromising a router or NAT on the path from the client to the STUN 1748 server. When the STUN request passes through the rogue router or 1749 NAT, it rewrites the source address of the packet to be that of the 1750 desired mapped address. This address cannot be arbitrary. If the 1751 attacker is on the public Internet (that is, there are no NATs 1752 between it and the STUN server), and the attacker doesn't modify the 1753 STUN request, the address has to have the property that packets sent 1754 from the STUN server to that address would route through the 1755 compromised router. This is because the STUN server will send the 1756 responses back to the source address of the request. With a modified 1757 source address, the only way they can reach the client is if the 1758 compromised router directs them there. If the attacker is on the 1759 public Internet, but they can modify the STUN request, they can 1760 insert a RESPONSE-ADDRESS attribute into the request, containing the 1761 actual source address of the STUN request. This will cause the 1762 server to send the response to the client, independent of the source 1763 address the STUN server sees. This gives the attacker the ability to 1764 forge an arbitrary source address when it forwards the STUN request. 1766 Todo: RESPONSE-ADDRESS has been removed from this version of the 1767 specification. Reword or remove above paragraph accordingly. 1769 If the attacker is on a private network (that is, there are NATs 1770 between it and the STUN server), the attacker will not be able to 1771 force the server to generate arbitrary mapped addresses in responses. 1772 They will only be able force the STUN server to generate mapped 1773 addresses which route to the private network. This is because the 1774 NAT between the attacker and the STUN server will rewrite the source 1775 address of the STUN request, mapping it to a public address that 1776 routes to the private network. Because of this, the attacker can 1777 only force the server to generate faked mapped addresses that route 1778 to the private network. Unfortunately, it is possible that a low 1779 quality NAT would be willing to map an allocated public address to 1780 another public address (as opposed to an internal private address), 1781 in which case the attacker could forge the source address in a STUN 1782 request to be an arbitrary public address. This kind of behavior 1783 from NATs does appear to be rare. 1785 13.2.4. Approach IV: Man in the Middle 1787 As an alternative to approach III (Section 13.2.3), if the attacker 1788 can place an element on the path from the client to the server, the 1789 element can act as a man-in-the-middle. In that case, it can 1790 intercept a STUN request, and generate a STUN response directly with 1791 any desired value of the mapped address field. Alternatively, it can 1792 forward the STUN request to the server (after potential 1793 modification), receive the response, and forward it to the client. 1794 When forwarding the request and response, this attack is subject to 1795 the same limitations on the mapped address described in Approach III 1796 (Section 13.2.3). 1798 13.2.5. Approach V: Response Injection Plus DoS 1800 In this approach, the attacker does not need to be a MitM (as in 1801 approaches III and IV). Rather, it only needs to be able to 1802 eavesdrop onto a network segment that carries STUN requests. This is 1803 easily done in multiple access networks such as ethernet or 1804 unprotected 802.11. To inject the fake response, the attacker 1805 listens on the network for a STUN request. When it sees one, it 1806 simultaneously launches a DoS attack on the STUN server, and 1807 generates its own STUN response with the desired mapped address 1808 value. The STUN response generated by the attacker will reach the 1809 client, and the DoS attack against the server is aimed at preventing 1810 the legitimate response from the server from reaching the client. 1811 Arguably, the attacker can do without the DoS attack on the server, 1812 so long as the faked response beats the real response back to the 1813 client, and the client uses the first response, and ignores the 1814 second (even though it's different). 1816 13.2.6. Approach VI: Duplication 1818 This approach is similar to approach V (Section 13.2.5). The 1819 attacker listens on the network for a STUN request. When it sees it, 1820 it generates its own STUN request towards the server. This STUN 1821 request is identical to the one it saw, but with a spoofed source IP 1822 address. The spoofed address is equal to the one that the attacker 1823 desires to have placed in the mapped address of the STUN response. 1824 In fact, the attacker generates a flood of such packets. The STUN 1825 server will receive the one original request, plus a flood of 1826 duplicate fake ones. It generates responses to all of them. If the 1827 flood is sufficiently large for the responses to congest routers or 1828 some other equipment, there is a reasonable probability that the one 1829 real response is lost (along with many of the faked ones), but the 1830 net result is that only the faked responses are received by the STUN 1831 client. These responses are all identical and all contain the mapped 1832 address that the attacker wanted the client to use. 1834 The flood of duplicate packets is not needed (that is, only one faked 1835 request is sent), so long as the faked response beats the real 1836 response back to the client, and the client uses the first response, 1837 and ignores the second (even though it's different). 1839 Note that, in this approach, launching a DoS attack against the STUN 1840 server or the IP network, to prevent the valid response from being 1841 sent or received, is problematic. The attacker needs the STUN server 1842 to be available to handle its own request. Due to the periodic 1843 retransmissions of the request from the client, this leaves a very 1844 tiny window of opportunity. The attacker must start the DoS attack 1845 immediately after the actual request from the client, causing the 1846 correct response to be discarded, and then cease the DoS attack in 1847 order to send its own request, all before the next retransmission 1848 from the client. Due to the close spacing of the retransmits (100ms 1849 to a few seconds), this is very difficult to do. 1851 Besides DoS attacks, there may be other ways to prevent the actual 1852 request from the client from reaching the server. Layer 2 1853 manipulations, for example, might be able to accomplish it. 1855 Fortunately, this approach is subject to the same limitations 1856 documented in Approach III (Section 13.2.3), which limit the range of 1857 mapped addresses the attacker can cause the STUN server to generate. 1859 13.3. Countermeasures 1861 STUN provides mechanisms to counter the approaches described above, 1862 and additional, non-STUN techniques can be used as well. 1864 First off, it is RECOMMENDED that networks with STUN clients 1865 implement ingress source filtering [7]. This is particularly 1866 important for the NATs themselves. As Section 13.2.3 explains, NATs 1867 which do not perform this check can be used as "reflectors" in DDoS 1868 attacks. Most NATs do perform this check as a default mode of 1869 operation. We strongly advise people that purchase NATs to ensure 1870 that this capability is present and enabled. 1872 Secondly, it is RECOMMENDED that STUN servers be run on hosts 1873 dedicated to STUN, with all UDP and TCP ports disabled except for the 1874 STUN ports. This is to prevent viruses and Trojan horses from 1875 infecting STUN servers, in order to prevent their compromise. This 1876 helps mitigate Approach I (Section 13.2.1). 1878 Thirdly, to prevent the DNS attack of Section 13.2.2, Section 8.1.2 1879 recommends that the client verify the credentials provided by the 1880 server with the name used in the DNS lookup. 1882 Finally, all of the attacks above rely on the client taking the 1883 mapped address it learned from STUN, and using it in application 1884 layer protocols. If encryption and message integrity are provided 1885 within those protocols, the eavesdropping and identity assumption 1886 attacks can be prevented. As such, applications that make use of 1887 STUN addresses in application protocols SHOULD use integrity and 1888 encryption, even if a SHOULD level strength is not specified for that 1889 protocol. For example, multimedia applications using STUN addresses 1890 to receive RTP traffic would use secure RTP [20]. 1892 The above three techniques are non-STUN mechanisms. STUN itself 1893 provides several countermeasures. 1895 Approaches IV (Section 13.2.4), when generating the response locally, 1896 and V (Section 13.2.5) require an attacker to generate a faked 1897 response. A faked response must match the 96-bit transaction ID of 1898 the request. The attack further prevented by using the message 1899 integrity mechanism provided in STUN, described in Section 11.8. 1901 Approaches III (Section 13.2.3), IV (Section 13.2.4), when using the 1902 relaying technique, and VI (Section 13.2.6), however, are not 1903 preventable through server signatures. All three approaches are most 1904 potent when the attacker can modify the request, inserting a 1905 RESPONSE-ADDRESS that routes to the client. Fortunately, such 1906 modifications are preventable using the message integrity techniques 1907 described in Section 11.8. However, these three approaches are still 1908 functional when the attacker modifies nothing but the source address 1909 of the STUN request. Sadly, this is the one thing that cannot be 1910 protected through cryptographic means, as this is the change that 1911 STUN itself is seeking to detect and report. It is therefore an 1912 inherent weakness in NAT, and not fixable in STUN. 1914 13.4. Residual Threats 1916 None of the countermeasures listed above can prevent the attacks 1917 described in Section 13.2.3 if the attacker is in the appropriate 1918 network paths. Specifically, consider the case in which the attacker 1919 wishes to convince client C that it has address V. The attacker needs 1920 to have a network element on the path between A and the server (in 1921 order to modify the request) and on the path between the server and V 1922 so that it can forward the response to C. Furthermore, if there is a 1923 NAT between the attacker and the server, V must also be behind the 1924 same NAT. In such a situation, the attacker can either gain access 1925 to all the application-layer traffic or mount the DDOS attack 1926 described in Section 13.1.1. Note that any host which exists in the 1927 correct topological relationship can be DDOSed. It need not be using 1928 STUN. 1930 14. IAB Considerations 1932 Todo: The diagnostic usages have been removed from this document, 1933 which reduces the brittleness of STUN. This section should be 1934 updated accordingly. 1936 The IAB has studied the problem of "Unilateral Self Address Fixing" 1937 (UNSAF), which is the general process by which a client attempts to 1938 determine its address in another realm on the other side of a NAT 1939 through a collaborative protocol reflection mechanism (RFC3424 [21]). 1940 STUN is an example of a protocol that performs this type of function. 1941 The IAB has mandated that any protocols developed for this purpose 1942 document a specific set of considerations. This section meets those 1943 requirements. 1945 14.1. Problem Definition 1947 From RFC3424 [21], any UNSAF proposal must provide: 1949 Precise definition of a specific, limited-scope problem that is to 1950 be solved with the UNSAF proposal. A short term fix should not be 1951 generalized to solve other problems; this is why "short term fixes 1952 usually aren't". 1954 The specific problem being solved by STUN is to provide a means for a 1955 client to obtain an address on the public Internet from a non- 1956 symmetric NAT, for the express purpose of receiving incoming UDP 1957 traffic from another host, targeted to that address. STUN does not 1958 address traversal of NATs using TCP, either incoming or outgoing, and 1959 does not address outgoing UDP communications. 1961 14.2. Exit Strategy 1963 From RFC3424 [21], any UNSAF proposal must provide: 1965 Description of an exit strategy/transition plan. The better short 1966 term fixes are the ones that will naturally see less and less use 1967 as the appropriate technology is deployed. 1969 STUN by itself does not provide an exit strategy. This is provided 1970 by techniques, such as Interactive Connectivity Establishment (ICE 1971 [12]), which allow a client to determine whether addresses learned 1972 from STUN are needed, or whether other addresses, such as the one on 1973 the local interface, will work when communicating with another host. 1974 With such a detection technique, as a client finds that the addresses 1975 provided by STUN are never used, STUN queries can cease to be made, 1976 thus allowing them to phase out. 1978 STUN can also help facilitate the introduction of other NAT traversal 1979 techniques such as MIDCOM [22]. As midcom-capable NATs are deployed, 1980 applications will, instead of using STUN (which also resides at the 1981 application layer), first allocate an address binding using midcom. 1982 However, it is a well-known limitation of MIDCOM that it only works 1983 when the agent knows the middleboxes through which its traffic will 1984 flow. Once bindings have been allocated from those middleboxes, a 1985 STUN detection procedure can validate that there are no additional 1986 middleboxes on the path from the public Internet to the client. If 1987 this is the case, the application can continue operation using the 1988 address bindings allocated from MIDCOM. If it is not the case, STUN 1989 provides a mechanism for self-address fixing through the remaining 1990 MIDCOM-unaware middleboxes. Thus, STUN provides a way to help 1991 transition to full MIDCOM-aware networks. 1993 14.3. Brittleness Introduced by STUN 1995 From RFC3424 [21], any UNSAF proposal must provide: 1997 Discussion of specific issues that may render systems more 1998 "brittle". For example, approaches that involve using data at 1999 multiple network layers create more dependencies, increase 2000 debugging challenges, and make it harder to transition. 2002 STUN introduces brittleness into the system in several ways: 2004 o The binding acquisition usage is dependant on NAT's behavior when 2005 forwarding UDP packets from arbitrary hosts on the public side of 2006 the NAT. Application specific processing will generally be 2007 needed. For symmetric NATs, the binding acquisition will not 2008 yield a usable address. The tight dependency on the specific type 2009 of NAT makes the protocol brittle. 2011 o STUN assumes that the server exists on the public Internet. If 2012 the server is located in another private address realm, the user 2013 may or may not be able to use its discovered address to 2014 communicate with other users. There is no way to detect such a 2015 condition. 2017 o The bindings allocated from the NAT need to be continuously 2018 refreshed. Since the timeouts for these bindings is very 2019 implementation specific, the refresh interval cannot easily be 2020 determined. When the binding is not being actively used to 2021 receive traffic, but to wait for an incoming message, the binding 2022 refresh will needlessly consume network bandwidth. 2024 o The use of the STUN server as an additional network element 2025 introduces another point of potential security attack. These 2026 attacks are largely prevented by the security measures provided by 2027 STUN, but not entirely. 2029 o The use of the STUN server as an additional network element 2030 introduces another point of failure. If the client cannot locate 2031 a STUN server, or if the server should be unavailable due to 2032 failure, the application cannot function. 2034 o The use of STUN to discover address bindings will result in an 2035 increase in latency for applications. For example, a Voice over 2036 IP application will see an increase of call setup delays equal to 2037 at least one RTT to the STUN server. 2039 o STUN imposes some restrictions on the network topologies for 2040 proper operation. If client A obtains an address from STUN server 2041 X, and sends it to client B, B may not be able to send to A using 2042 that IP address. The address will not work if any of the 2043 following is true: 2045 * The STUN server is not in an address realm that is a common 2046 ancestor (topologically) of both clients A and B. For example, 2047 consider client A and B, both of which have residential NAT 2048 devices. Both devices connect them to their cable operators, 2049 but both clients have different providers. Each provider has a 2050 NAT in front of their entire network, connecting it to the 2051 public Internet. If the STUN server used by A is in A's cable 2052 operator's network, an address obtained by it will not be 2053 usable by B. The STUN server must be in the network which is a 2054 common ancestor to both - in this case, the public Internet. 2056 * The STUN server is in an address realm that is a common 2057 ancestor to both clients, but both clients are behind the same 2058 NAT connecting to that address realm. For example, if the two 2059 clients in the previous example had the same cable operator, 2060 that cable operator had a single NAT connecting their network 2061 to the public Internet, and the STUN server was on the public 2062 Internet, the address obtained by A would not be usable by B. 2063 That is because some NATs will not accept an internal packet 2064 sent to a public IP address which is mapped back to an internal 2065 address. To deal with this, additional protocol mechanisms or 2066 configuration parameters need to be introduced which detect 2067 this case. 2069 o Most significantly, STUN introduces potential security threats 2070 which cannot be eliminated. This specification describes 2071 heuristics that can be used to mitigate the problem, but it is 2072 provably unsolvable given what STUN is trying to accomplish. 2073 These security problems are described fully in Section 13. 2075 14.4. Requirements for a Long Term Solution 2077 From RFC3424 [21], any UNSAF proposal must provide: 2079 Identify requirements for longer term, sound technical solutions 2080 -- contribute to the process of finding the right longer term 2081 solution. 2083 Our experience with STUN has led to the following requirements for a 2084 long term solution to the NAT problem: 2086 o Requests for bindings and control of other resources in a NAT need 2087 to be explicit. Much of the brittleness in STUN derives from its 2088 guessing at the parameters of the NAT, rather than telling the NAT 2089 what parameters to use. 2091 o Control needs to be in-band. There are far too many scenarios in 2092 which the client will not know about the location of middleboxes 2093 ahead of time. Instead, control of such boxes needs to occur in- 2094 band, traveling along the same path as the data will itself 2095 travel. This guarantees that the right set of middleboxes are 2096 controlled. This is only true for first-party controls; third- 2097 party controls are best handled using the MIDCOM framework. 2099 o Control needs to be limited. Users will need to communicate 2100 through NATs which are outside of their administrative control. 2101 In order for providers to be willing to deploy NATs which can be 2102 controlled by users in different domains, the scope of such 2103 controls needs to be extremely limited - typically, allocating a 2104 binding to reach the address where the control packets are coming 2105 from. 2107 o Simplicity is Paramount. The control protocol will need to be 2108 implement in very simple clients. The servers will need to 2109 support extremely high loads. The protocol will need to be 2110 extremely robust, being the precursor to a host of application 2111 protocols. As such, simplicity is key. 2113 14.5. Issues with Existing NAPT Boxes 2115 From RFC3424 [21], any UNSAF proposal must provide: 2117 Discussion of the impact of the noted practical issues with 2118 existing, deployed NA[P]Ts and experience reports. 2120 Several of the practical issues with STUN involve future proofing - 2121 breaking the protocol when new NAT types get deployed. Fortunately, 2122 this is not an issue at the current time, since most of the deployed 2123 NATs are of the types assumed by STUN. The primary usage STUN has 2124 found is in the area of VoIP, to facilitate allocation of addresses 2125 for receiving RTP [14] traffic. In that application, the periodic 2126 keepalives are usually (but not always) provided by the RTP traffic 2127 itself. However, several practical problems arise for RTP. First, 2128 in the absence of [23], RTP assumes that RTCP traffic is on a port 2129 one higher than the RTP traffic. This pairing property cannot be 2130 guaranteed through NATs that are not directly controllable. As a 2131 result, RTCP traffic may not be properly received. [23] mitigates 2132 this by allowing the client to signal a different port for RTCP but 2133 there will be interoperability problems for some time. 2135 For VoIP, silence suppression can cause a gap in the transmission of 2136 RTP packets. If that silence period exceeds the NAT binding timeout, 2137 this could result in the loss of a NAT binding in the middle of a 2138 call. This can be mitigated by sending occasional packets to keep 2139 the binding alive. However, the result is additional brittleness. 2141 14.6. In Closing 2143 The problems with STUN are not design flaws in STUN. The problems in 2144 STUN have to do with the lack of standardized behaviors and controls 2145 in NATs. The result of this lack of standardization has been a 2146 proliferation of devices whose behavior is highly unpredictable, 2147 extremely variable, and uncontrollable. STUN does the best it can in 2148 such a hostile environment. Ultimately, the solution is to make the 2149 environment less hostile, and to introduce controls and standardized 2150 behaviors into NAT. However, until such time as that happens, STUN 2151 provides a good short term solution given the terrible conditions 2152 under which it is forced to operate. 2154 15. IANA Considerations 2156 IANA is hereby requsted to create two new registries STUN Message 2157 Types and STUN Attributes. IANA must assign the following values to 2158 both registeries before publication of this document as an RFC. New 2159 values for both STUN Message Type and STUN Attributes are assigned 2160 through the IETF consensus process via RFCs approved by the IESG. 2162 15.1. STUN Message Type Registry 2164 For STUN Message Types that are request message types, they MUST be 2165 registered including associated Response message types and Error 2166 Response message types, and those responses must have values that are 2167 0x100 and 0x110 higher than their respective Request values. 2169 For STUN Message Types that are Indication message types, no 2170 associated restriction applies. As the message type field is only 14 2171 bits the range of valid values is 0x001 through 0x3FFF. 2173 The initial STUN Message Types are: 2175 0x0001 : Binding Request 2176 0x0101 : Binding Response 2177 0x0111 : Binding Error Response 2178 0x0002 : Shared Secret Request 2179 0x0102 : Shared Secret Response 2180 0x0112 : Shared Secret Error Response 2181 0x0002 : Shared Secret Request 2182 0x0102 : Shared Secret Responsed 2183 0x0112 : Shared Secret Error Response 2185 15.2. STUN Attribute Registry 2187 STUN attributes values above 0x7FFF are considered optional 2188 attributes; attributes equal to 0x7FFF or below are considered 2189 mandatory attributes. The STUN client and STUN server process 2190 optional and mandatory attributes differently. IANA should assign 2191 values based on the RFC consensus process. 2193 The initial STUN Attributes are: 2195 0x0001: MAPPED-ADDRESS 2196 0x0002: RESPONSE-ADDRESS 2197 0x0003: CHANGE-REQUEST 2198 0x0004: SOURCE-ADDRESS 2199 0X0005: CHANGED-ADDRESS 2200 0x0006: USERNAME 2201 0x0007: PASSWORD 2202 0x0008: MESSAGE-INTEGRITY 2203 0x0009: ERROR-CODE 2204 0x000A: UNKNOWN-ATTRIBUTES 2205 0x000B: REFLECTED-FROM 2206 0x000E: ALTERNATE-SERVER 2207 0x0014: REALM 2208 0x0015: NONCE 2209 0x0020: XOR-MAPPED-ADDRESS 2210 0x8022: SERVER 2211 0x8023: ALTERNATE-SERVER 2212 0x8024: BINDING-LIFETIME 2214 16. Changes Since RFC 3489 2216 This specification updates RFC3489 [13]. This specification differs 2217 from RFC3489 in the following ways: 2219 o Removed the usage of STUN for NAT type detection and binding 2220 lifetime discovery. These techniques have proven overly brittle 2221 due to wider variations in the types of NAT devices than described 2222 in this document. Removed the RESPONSE-ADDRESS, CHANGED-ADDRESS, 2223 CHANGE-REQUEST, SOURCE-ADDRESS, and REFLECTED-FROM attributes. 2225 o Removed the STUN example that centered around the separation of 2226 the control and media planes. Instead, provided more information 2227 on using STUN with protocols. 2229 o Added a fixed 32-bit magic cookie and reduced length of 2230 transaction ID by 32 bits. The magic cookie begins at the same 2231 offset as the original transaction ID. 2233 o Added the XOR-MAPPED-ADDRESS attribute, which is included in 2234 Binding Responses if the magic cookie is present in the request. 2235 Otherwise the RFC3489 behavior is retained (that is, Binding 2236 Response includes MAPPED-ADDRESS). See discussion in XOR-MAPPED- 2237 ADDRESS regarding this change. 2239 o Explicitly point out that the most significant two bits of STUN 2240 are 0b00, allowing easy differentiation with RTP packets when used 2241 with ICE. 2243 o Added support for IPv6. Made it clear that an IPv4 client could 2244 get a v6 mapped address, and vice-a-versa. 2246 o Added the SERVER, REALM, NONCE, and ALTERNATE-SERVER attributes. 2248 o Removed recommendation to continue listening for STUN Responses 2249 for 10 seconds in an attempt to recognize an attack. 2251 17. Acknowledgements 2253 The authors would like to thank Cedric Aoun, Pete Cordell, Cullen 2254 Jennings, Bob Penfield and Chris Sullivan for their comments, and 2255 Baruch Sterman and Alan Hawrylyshen for initial implementations. 2256 Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning 2257 Schulzrinne for IESG and IAB input on this work. 2259 18. References 2261 18.1. Normative References 2263 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2264 Levels", BCP 14, RFC 2119, March 1997. 2266 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 2268 [3] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 2269 draft-rosenberg-midcom-turn-08 (work in progress), 2270 September 2005. 2272 [4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2273 specifying the location of services (DNS SRV)", RFC 2782, 2274 February 2000. 2276 [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2278 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2279 RFC 2246, January 1999. 2281 [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 2282 Denial of Service Attacks which employ IP Source Address 2283 Spoofing", BCP 38, RFC 2827, May 2000. 2285 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2286 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 2287 Basic and Digest Access Authentication", RFC 2617, June 1999. 2289 18.2. Informational References 2291 [9] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2292 for Message Authentication", RFC 2104, February 1997. 2294 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2295 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2296 Session Initiation Protocol", RFC 3261, June 2002. 2298 [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2299 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2300 HTTP/1.1", RFC 2616, June 1999. 2302 [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 2303 Methodology for Network Address Translator (NAT) Traversal for 2304 Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in 2305 progress), October 2005. 2307 [13] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 2308 - Simple Traversal of User Datagram Protocol (UDP) Through 2309 Network Address Translators (NATs)", RFC 3489, March 2003. 2311 [14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2312 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2313 RFC 3550, July 2003. 2315 [15] Jennings, C. and R. Mahy, "Managing Client Initiated 2316 Connections in the Session Initiation Protocol (SIP)", 2317 draft-ietf-sip-outbound-01 (work in progress), October 2005. 2319 [16] Kohl, J. and B. Neuman, "The Kerberos Network Authentication 2320 Service (V5)", RFC 1510, September 1993. 2322 [17] Senie, D., "Network Address Translator (NAT)-Friendly 2323 Application Design Guidelines", RFC 3235, January 2002. 2325 [18] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 2326 IP Network Address Translator", RFC 3027, January 2001. 2328 [19] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2329 Session Description Protocol (SDP)", RFC 3264, June 2002. 2331 [20] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2332 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2333 RFC 3711, March 2004. 2335 [21] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 2336 Address Fixing (UNSAF) Across Network Address Translation", 2337 RFC 3424, November 2002. 2339 [22] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 2340 Rayhan, "Middlebox communication architecture and framework", 2341 RFC 3303, August 2002. 2343 [23] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2344 Session Description Protocol (SDP)", RFC 3605, October 2003. 2346 Authors' Addresses 2348 Jonathan Rosenberg 2349 Cisco Systems 2350 600 Lanidex Plaza 2351 Parsippany, NJ 07054 2352 US 2354 Phone: +1 973 952-5000 2355 Email: jdrosen@cisco.com 2356 URI: http://www.jdrosen.net 2358 Christian Huitema 2359 Microsoft 2360 One Microsoft Way 2361 Redmond, WA 98052 2362 US 2364 Email: huitema@microsoft.com 2366 Rohan Mahy 2367 Plantronics 2368 345 Encinal Street 2369 Santa Cruz, CA 95060 2370 US 2372 Email: rohan@ekabal.com 2374 Dan Wing 2375 Cisco Systems 2376 771 Alder Drive 2377 San Jose, CA 95035 2378 US 2380 Email: dwing@cisco.com 2382 Intellectual Property Statement 2384 The IETF takes no position regarding the validity or scope of any 2385 Intellectual Property Rights or other rights that might be claimed to 2386 pertain to the implementation or use of the technology described in 2387 this document or the extent to which any license under such rights 2388 might or might not be available; nor does it represent that it has 2389 made any independent effort to identify any such rights. Information 2390 on the procedures with respect to rights in RFC documents can be 2391 found in BCP 78 and BCP 79. 2393 Copies of IPR disclosures made to the IETF Secretariat and any 2394 assurances of licenses to be made available, or the result of an 2395 attempt made to obtain a general license or permission for the use of 2396 such proprietary rights by implementers or users of this 2397 specification can be obtained from the IETF on-line IPR repository at 2398 http://www.ietf.org/ipr. 2400 The IETF invites any interested party to bring to its attention any 2401 copyrights, patents or patent applications, or other proprietary 2402 rights that may cover technology that may be required to implement 2403 this standard. Please address the information to the IETF at 2404 ietf-ipr@ietf.org. 2406 Disclaimer of Validity 2408 This document and the information contained herein are provided on an 2409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2411 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2412 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2413 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2416 Copyright Statement 2418 Copyright (C) The Internet Society (2006). This document is subject 2419 to the rights, licenses and restrictions contained in BCP 78, and 2420 except as set forth therein, the authors retain all their rights. 2422 Acknowledgment 2424 Funding for the RFC Editor function is currently provided by the 2425 Internet Society.