idnits 2.17.1 draft-ietf-behave-rfc3489bis-04.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 2832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2822. ** 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 33 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == 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 (July 11, 2006) is 6497 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) ** Obsolete normative reference: RFC 2818 (ref. '4') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '10') (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-08 == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-udp-07 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '13') (Obsoleted by RFC 5389) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-00 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-03 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '23') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 8 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: January 12, 2007 C. Huitema 5 Microsoft 6 R. Mahy 7 Plantronics 8 D. Wing 9 Cisco Systems 10 July 11, 2006 12 Simple Traversal Underneath Network Address Translators (NAT) (STUN) 13 draft-ietf-behave-rfc3489bis-04 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 January 12, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 Simple Traversal Underneath NATs (STUN) is a lightweight protocol 47 that serves as a tool for application protocols in dealing with NAT 48 traversal. It allows a client to determine the IP address and port 49 allocated to them by a NAT and to keep NAT bindings open. It can 50 also serve as a check for connectivity between a client and a server 51 in the presence of NAT, and for the client to detect failure of the 52 server. STUN works with many existing NATs, and does not require any 53 special behavior from them. As a result, it allows a wide variety of 54 applications to work through existing NAT infrastructure. 56 Table of Contents 58 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 63 6. STUN Message Structure . . . . . . . . . . . . . . . . . . . . 11 64 7. STUN Transactions . . . . . . . . . . . . . . . . . . . . . . 14 65 7.1. Request/Response Transactions . . . . . . . . . . . . . . 14 66 7.2. Indications . . . . . . . . . . . . . . . . . . . . . . . 15 67 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 15 68 8.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 69 8.2. Obtaining a Shared Secret . . . . . . . . . . . . . . . . 16 70 8.3. Request/Response Transactions . . . . . . . . . . . . . . 17 71 8.3.1. Formulating the Request Message . . . . . . . . . . . 17 72 8.3.2. Processing Responses . . . . . . . . . . . . . . . . . 18 73 8.4. Indication Transactions . . . . . . . . . . . . . . . . . 21 74 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 75 9.1. Request/Response Transactions . . . . . . . . . . . . . . 22 76 9.1.1. Receive Request Message . . . . . . . . . . . . . . . 23 77 9.1.2. Constructing the Response . . . . . . . . . . . . . . 25 78 9.1.3. Sending the Response . . . . . . . . . . . . . . . . . 26 79 9.2. Indication Transactions . . . . . . . . . . . . . . . . . 26 80 10. Demultiplexing of STUN and Application Traffic . . . . . . . . 27 81 11. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 28 82 11.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 28 83 11.2. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 29 84 11.3. PASSWORD . . . . . . . . . . . . . . . . . . . . . . . . 29 85 11.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 30 86 11.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 30 87 11.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 30 88 11.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 11.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 11.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 32 91 11.10. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 33 92 11.11. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 34 93 11.12. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 34 94 11.13. REFRESH-INTERVAL . . . . . . . . . . . . . . . . . . . . 34 95 12. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 12.1. Binding Discovery . . . . . . . . . . . . . . . . . . . . 35 97 12.1.1. Applicability . . . . . . . . . . . . . . . . . . . . 35 98 12.1.2. Client Discovery of Server . . . . . . . . . . . . . . 36 99 12.1.3. Server Determination of Usage . . . . . . . . . . . . 36 100 12.1.4. New Requests or Indications . . . . . . . . . . . . . 37 101 12.1.5. New Attributes . . . . . . . . . . . . . . . . . . . . 37 102 12.1.6. New Error Response Codes . . . . . . . . . . . . . . . 37 103 12.1.7. Client Procedures . . . . . . . . . . . . . . . . . . 37 104 12.1.8. Server Procedures . . . . . . . . . . . . . . . . . . 37 105 12.1.9. Security Considerations for Binding Discovery . . . . 37 106 12.2. Connectivity Check . . . . . . . . . . . . . . . . . . . 37 107 12.2.1. Applicability . . . . . . . . . . . . . . . . . . . . 37 108 12.2.2. Client Discovery of Server . . . . . . . . . . . . . . 38 109 12.2.3. Server Determination of Usage . . . . . . . . . . . . 38 110 12.2.4. New Requests or Indications . . . . . . . . . . . . . 38 111 12.2.5. New Attributes . . . . . . . . . . . . . . . . . . . . 39 112 12.2.6. New Error Response Codes . . . . . . . . . . . . . . . 39 113 12.2.7. Client Procedures . . . . . . . . . . . . . . . . . . 39 114 12.2.8. Server Procedures . . . . . . . . . . . . . . . . . . 39 115 12.2.9. Security Considerations for Connectivity Check . . . . 39 116 12.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 39 117 12.3.1. Applicability . . . . . . . . . . . . . . . . . . . . 39 118 12.3.2. Client Discovery of Server . . . . . . . . . . . . . . 40 119 12.3.3. Server Determination of Usage . . . . . . . . . . . . 40 120 12.3.4. New Requests or Indications . . . . . . . . . . . . . 40 121 12.3.5. New Attributes . . . . . . . . . . . . . . . . . . . . 40 122 12.3.6. New Error Response Codes . . . . . . . . . . . . . . . 40 123 12.3.7. Client Procedures . . . . . . . . . . . . . . . . . . 41 124 12.3.8. Server Procedures . . . . . . . . . . . . . . . . . . 41 125 12.3.9. Security Considerations for NAT Keepalives . . . . . . 41 126 12.4. Short-Term Password . . . . . . . . . . . . . . . . . . . 41 127 12.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 42 128 12.4.2. Client Discovery of Server . . . . . . . . . . . . . . 42 129 12.4.3. Server Determination of Usage . . . . . . . . . . . . 42 130 12.4.4. New Requests or Indications . . . . . . . . . . . . . 42 131 12.4.5. New Attributes . . . . . . . . . . . . . . . . . . . . 43 132 12.4.6. New Error Response Codes . . . . . . . . . . . . . . . 43 133 12.4.7. Client Procedures . . . . . . . . . . . . . . . . . . 43 134 12.4.8. Server Procedures . . . . . . . . . . . . . . . . . . 44 135 12.4.9. Security Considerations for Short-Term Password . . . 44 136 13. Security Considerations . . . . . . . . . . . . . . . . . . . 46 137 13.1. Attacks on STUN . . . . . . . . . . . . . . . . . . . . . 46 138 13.1.1. Attack I: DDoS Against a Target . . . . . . . . . . . 46 139 13.1.2. Attack II: Silencing a Client . . . . . . . . . . . . 47 140 13.1.3. Attack III: Assuming the Identity of a Client . . . . 47 141 13.1.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 47 142 13.2. Launching the Attacks . . . . . . . . . . . . . . . . . . 47 143 13.2.1. Approach I: Compromise a Legitimate STUN Server . . . 48 144 13.2.2. Approach II: DNS Attacks . . . . . . . . . . . . . . . 48 145 13.2.3. Approach III: Rogue Router or NAT . . . . . . . . . . 48 146 13.2.4. Approach IV: Man in the Middle . . . . . . . . . . . . 49 147 13.2.5. Approach V: Response Injection Plus DoS . . . . . . . 49 148 13.2.6. Approach VI: Duplication . . . . . . . . . . . . . . . 50 149 13.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 50 150 13.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 52 151 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 52 152 14.1. Problem Definition . . . . . . . . . . . . . . . . . . . 52 153 14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 52 154 14.3. Brittleness Introduced by STUN . . . . . . . . . . . . . 53 155 14.4. Requirements for a Long Term Solution . . . . . . . . . . 54 156 14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 55 157 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 158 15.1. STUN Message Type Registry . . . . . . . . . . . . . . . 56 159 15.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 56 160 16. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 57 161 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 162 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 163 18.1. Normative References . . . . . . . . . . . . . . . . . . 58 164 18.2. Informational References . . . . . . . . . . . . . . . . 59 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 166 Intellectual Property and Copyright Statements . . . . . . . . . . 62 168 1. Applicability Statement 170 This protocol is not a cure-all for the problems associated with NAT. 171 It is a tool that is typically used in conjunction with other 172 protocols, such as Interactive Connectivity Establishment (ICE) [11] 173 for a more complete solution. The binding discovery usage, defined 174 by this specification, can be used by itself with numerous 175 application protocols as a solution for NAT traversal. However, when 176 used in that way, STUN will not work with applications that require 177 incoming TCP connections through NAT. It will allow incoming UDP 178 packets through NAT, but only through a subset of existing NAT types. 179 In particular, the STUN binding usage by itself does not enable 180 incoming UDP packets through NATs whose mapping property is address 181 dependent or address and port dependent [12]. Furthermore, the 182 binding usage, when used by itself, does not work when a client is 183 communicating with a peer which happens to be behind the same NAT. 184 Nor will it work when the STUN server is not in a common shared 185 address realm. 187 The STUN relay usage, defined in [14], allows a client to obtain an 188 IP address and port that actually reside on the STUN server. The 189 STUN relay usage, when used by itself, eliminates all of the 190 limitations of using the binding usage by itself, as described above. 191 However, it requires a server to act as a relay for application 192 traffic, which can be expensive to provide, operate and manage. 194 For multimedia protocols based on the offer/answer model [20], 195 including the Session Initiation Protocol (SIP) [9], Interactive 196 Connectivity Establishment (ICE) uses both the binding usage and 197 relay usage, and furthermore makes use of the connectivity check 198 usage defined here to help decide which of those two mechanisms ought 199 to be used. 201 Implementors should be aware of the specific deployment scenarios 202 that are of interest, and of the specific protocol (whether its SIP 203 or something else) in order to determine whether STUN is suitable as 204 a tool to facilitate NAT traversal, and which usage should be used. 206 2. Introduction 208 Network Address Translators (NATs), while providing many benefits, 209 also come with many drawbacks. The most troublesome of those 210 drawbacks is the fact that they break many existing IP applications, 211 and make it difficult to deploy new ones. Guidelines have been 212 developed [18] that describe how to build "NAT friendly" protocols, 213 but many protocols simply cannot be constructed according to those 214 guidelines. Examples of such protocols include almost all peer-to- 215 peer protocols, such as multimedia communications, file sharing and 216 games. 218 To combat this problem, Application Layer Gateways (ALGs) have been 219 embedded in NATs. ALGs perform the application layer functions 220 required for a particular protocol to traverse a NAT. Typically, 221 this involves rewriting application layer messages to contain 222 translated addresses, rather than the ones inserted by the sender of 223 the message. ALGs have serious limitations, including scalability, 224 reliability, and speed of deploying new applications. 226 Many existing proprietary protocols, such as those for online games 227 (such as the games described in RFC3027 [19]) and Voice over IP, have 228 developed tricks that allow them to operate through NATs without 229 changing those NATs and without relying on ALG behavior in the NATs. 230 This document takes some of those ideas and codifies them into an 231 interoperable protocol that can meet the needs of many applications. 233 The protocol described here, Simple Traversal Underneath NAT (STUN), 234 provides a toolkit of functions. These functions allow entities 235 behind a NAT to learn the address bindings allocated by the NAT, to 236 keep those bindings open, and communicate with other STUN-aware 237 entities to validate connectivity and liveness. STUN requires no 238 changes to NATs, and works with an arbitrary number of NATs in tandem 239 between the application entity and the public Internet. 241 3. Terminology 243 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 244 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 245 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 246 [1] and indicate requirement levels for compliant STUN 247 implementations. 249 4. Definitions 251 STUN Client: A STUN client (also just referred to as a client) is an 252 entity that generates STUN requests and receives STUN responses. 253 Clients can also generate STUN indications. 255 STUN Server: A STUN Server (also just referred to as a server) is an 256 entity that receives STUN requests, and sends STUN responses. 257 Servers also send STUN indications. 259 Transport Address: The combination of an IP address and (UDP or TCP) 260 port. 262 Reflexive Transport Address: A transport address learned by a client 263 which identifies that client as seen by another host on an IP 264 network, typically a STUN server. When there is an intervening 265 NAT between the client and the other host, the reflexive transport 266 address represents the binding allocated to the client on the 267 public side of the NAT. Reflexive transport addresses are learned 268 from the mapped address attribute (MAPPED-ADDRESS or XOR-MAPPED- 269 ADDRESS) in STUN responses. 271 Mapped Address: The source IP address and port of the STUN Binding 272 Request packet received by the STUN server and inserted into the 273 mapped address attribute (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) of 274 the Binding Response message. 276 Long Term Credential: A username and associated password which 277 represent a shared secret between client and server. Long term 278 credentials are generally granted to the client when a subscriber 279 enrolles in a service and persists until the subscriber leaves the 280 service or explicitly changes the credential. 282 Long Term Password: The password from a long term credential. 284 Short Term Credential: A temporary username and associated password 285 which represent a shared secret between client and server. A 286 short term credential has an explicit temporal scope, which may be 287 based on a specific amount of time (such as 5 minutes) or on an 288 event (such as termination of a SIP dialog). The specific scope 289 of a short term credential is defined by the application usage. A 290 short term credential can be obtained from a Shared Secret 291 request, though other mechanisms are possible. 293 Short Term Password: The password component of a short term 294 credential. 296 5. Overview of Operation 298 This section is descriptive only. Normative behavior is described in 299 Section 8 and Section 9 300 /-----\ 301 // STUN \\ 302 | Server | 303 \\ // 304 \-----/ 306 +--------------+ Public Internet 307 ................| NAT 2 |....................... 308 +--------------+ 310 +--------------+ Private NET 2 311 ................| NAT 1 |....................... 312 +--------------+ 314 /-----\ 315 // STUN \\ 316 | Client | 317 \\ // Private NET 1 318 \-----/ 320 Figure 1: Typical STUN Server Configuration 322 The typical STUN configuration is shown in Figure 1. A STUN client 323 is connected to private network 1. This network connects to private 324 network 2 through NAT 1. Private network 2 connects to the public 325 Internet through NAT 2. The STUN server resides on the public 326 Internet. 328 STUN is a simple client-server protocol. It supports two types of 329 transactions. One is a request/response transaction in which client 330 sends a request to a server, and the server returns a response. The 331 second are indications which are initiated by the server or the 332 client and do not elicit a response. There are two types of requests 333 defined in this specification - Binding Requests and Shared Secret 334 Requests. There are no indications defined by this specification. 336 Binding Requests are sent from the client towards the server. When 337 the Binding Request arrives at the STUN server, it may have passed 338 through one or more NATs between the STUN client and the STUN server 339 (in Figure 1, there were two such NATs). As a result, the source 340 transport address of the request received by the server will be the 341 mapped address created by the NAT closest to the server. The STUN 342 server copies that source IP address and port into a STUN Binding 343 Response, and sends it back to the source IP address and port of the 344 STUN request. Every type of NAT will route that response so that it 345 arrives at the STUN client. From this response, the client knows its 346 IP address and port allocated by the outermost NAT towards the STUN 347 server. 349 STUN provides several mechanisms for authentication and message 350 integrity. The client and server can share a pre-provisioned shared 351 secret, which is used for a digest challenge/response authentication 352 operation. This is known as a long-term credential or long-term 353 shared secret. 355 Alternatively, if the shared secret is obtained by some out-of-bands 356 means and has a lifetime that is temporally scoped, a simple HMAC is 357 provided, without a challenge operation. This is known as a short 358 term credential or short term password. Short-term passwords are 359 useful when there is no long-term relationship with a STUN server and 360 thus no long-term password is shared between the STUN client and STUN 361 server. Even if there is a long-term password, the issuance of a 362 short-term password is useful to prevent dictionary attacks. 364 STUN itself provides a mechanism for obtaining such short term 365 credentials, using the Shared Secret Request. Shared Secret requests 366 are sent over TLS [5] over TCP. Shared Secret Requests ask the 367 server to return a temporary username and password that can be used 368 in subsequent STUN requests. 370 There are many ways in which these basic mechanisms can be used to 371 accomplish a specific task. As a result, STUN has the notion of a 372 usage. A usage is a specific use case for the STUN protocol. The 373 usage will define what it is that the client does with the mapped 374 address it receives, defines when the client would send Binding 375 requests and why, and would constrain the set of authentication 376 mechanisms or attributes that get used in that usage. STUN usages 377 can also define new attributes and message types, if needed. This 378 specification defines four STUN usages - binding discovery, 379 connectivity check, NAT keepalives, and short-term password. 381 The binding discovery usage is sometimes referred to as 'classic 382 STUN', since it is the usage originally envisioned in RFC 3489 [13], 383 the predecessor to this specification. The purpose of the binding 384 discovery usage is for the client to obtain an IP address and port at 385 which it is reachable, that it can include in application layer 386 signaling messages, such as the Session Description Protocol (SDP) 387 [17] body of a SIP message, utilized to receive Real Time Transport 388 Protocol (RTP [15]) traffic. In this usage, the STUN server is 389 typically located on the public Internet and run by the service 390 provider offering the application service (such as a SIP provider), 391 though this need not be the case. The client would utilize the STUN 392 request just prior to sending a protocol message (such as a SIP 393 INVITE request or 200 OK response) which requires the client to embed 394 its IP address in it. 396 In the connectivity check usage, two hosts on the Internet have used 397 a protocol such as SIP to rendezvous, and have used it to exchange IP 398 addresses and ports at which they might be reachable. However, each 399 host does not know whether it can actually connect to the other host 400 using that IP address and port, and whether that remote host can 401 reach it. To figure this out, each host will send a STUN Binding 402 Request to the other host, and if a reply is received, it knows that 403 the remote host was reachable. Furthermore, the mapped address 404 returned in the response tells the host the address and port at which 405 it can be reached by the remote host. The connectivity check usage 406 is used by ICE [11], for example. 408 In the binding keepalive usage, a client sends an application 409 protocol message (such as a SIP REGISTER message) to a server. The 410 server notes the source IP address and port of the request, and 411 remembers it. Later on, if it needs to reach the client, it sends a 412 message to that IP address and port. However, this message will only 413 be received by the client if the binding in the NAT is still alive. 414 Since bindings allocated by NAT expire unless refreshed, the client 415 must generate keepalive messages towards the server to refresh the 416 binding. Rather than use expensive application layer messages, a 417 STUN binding request is sent by the client to the server, and is sent 418 to the exact same IP address and port used by the server for the 419 application protocol. In the case of SIP, this would typically mean 420 port 5060 or 5061. This has the effect of keeping the bindings in 421 the NAT alive. The STUN binding responses also inform the client 422 that the server is still responsive, and also inform the client if 423 its IP address and port towards the server have changed, in which 424 case it may need application layer protocol messaging to update its 425 IP address and port as seen by the server. The binding keepalive 426 usage is used by the SIP outbound mechanism, for example [16]. 428 These three usages all utilize the same Binding Request message, and 429 all require the same basic processing on the server. They differ 430 only in where the server is (embedded in a peer host, a standalone 431 server in the network, or embedded in an application layer server), 432 when the Binding Request is used, and what the client does with the 433 mapped address that is returned. 435 The short-term password usage makes use of the Shared Secret request 436 and response, and allows a client to obtain a temporary set of 437 credentials to authenticate itself with the STUN server. The 438 credentials obtained from this usage can be used in requests for any 439 other usage. 441 Many of the usages (such as the binding keepalive and connectivity 442 check usages) require STUN messages to be sent on the same IP address 443 and port as some application protocol, such as RTP or SIP. To 444 facilitate the demultiplexing of the two, STUN defines a special 445 field in the message called the magic cookie, which is a fixed 32 bit 446 value that identifies STUN traffic. STUN requests also contain a 447 fingerprint, which is a cryptographic hash of the message, that allow 448 for validation that the message was a STUN request and not a data 449 packet that happened to have the same 32 bit value in the right place 450 in the message. 452 STUN servers can be discovered through DNS, though this is not 453 necessary in all usages. For those usages where it is needed, STUN 454 makes use of SRV records [3] to facilitate discovery. This discovery 455 allows for different IP addresses and ports to be found for different 456 usages. 458 6. STUN Message Structure 460 STUN messages are TLV (type-length-value) encoded using big endian 461 (network ordered) binary. STUN messages are encoded using binary 462 fields. All integer fields are carried in network byte order, that 463 is, most significant byte (octet) first. This byte order is commonly 464 known as big-endian. The transmission order is described in detail 465 in Appendix B of RFC791 [2]. Unless otherwise noted, numeric 466 constants are in decimal (base 10). All STUN messages start with a 467 single STUN header followed by a STUN payload. The payload is a 468 series of STUN attributes, the set of which depends on the message 469 type. The STUN header contains a STUN message type, transaction ID, 470 and length. The length indicates the total length of the STUN 471 payload, not including the 20-byte header. 473 There are two types of transactions in STUN - request/response 474 transactions, which utilize a request message and a response message, 475 and an indication transaction, which utilizes a single indication 476 message. Furthermore, responses are broken into two types - success 477 responses and error responses. The specific message (for example, 478 that it is a Binding Response or a Shared Secret Request) is encoded 479 into the message type field of the STUN header. For a particular 480 request message, its success response has a type that is always 0x100 481 higher than its own type, and its error response has a type that is 482 0x110 higher than its own type. Extensions defining new requests, 483 responses and error responses MUST use message type values 0x100 and 484 0x110 higher for their success and error responses, respectively. 486 STUN Requests are sent reliably. STUN can run over UDP or TCP. When 487 run over UDP, STUN requests are retransmitted in order to achieve 488 reliability. The transaction ID is used to correlate requests and 489 responses. 491 An indication message can be sent from the client to the server, or 492 from the server to the client. Indication messages can be sent over 493 TCP or UDP. STUN itself does not provide reliability for these 494 messages, though they will be delivered reliably when sent over TCP. 495 Indication messages do not have an associated success response 496 message type or associated error response message type. Indication 497 messages can be sent from the server to the client or client to 498 server. The transaction ID is used to distinguish indication 499 messages. 501 All STUN messages consist of a 20 byte header: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |0 0| STUN Message Type | Message Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Magic Cookie | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Transaction ID 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Figure 2: Format of STUN Message Header 519 The most significant two bits of every STUN message are both zeroes. 520 This, combined with the magic cookie and the fingerprint attribute, 521 aid in differentiating STUN packets from other protocols when STUN is 522 multiplexed with other protocols on the same port. 524 The STUN message types Binding Request, Response, and Error Response 525 are defined in Section 8 and Section 9.1. The Shared Secret Request, 526 Response, and Error Response are described in Section 12.4. Their 527 values are enumerated in Section 15. 529 The message length is the size, in bytes, of the message not 530 including the 20 byte STUN header. 532 The magic cookie is a fixed value, 0x2112A442. In the previous 533 version of this specification [13] this field was part of the 534 transaction ID. This fixed value is used as part of the 535 identification of a STUN message when STUN is multiplexed with other 536 protocols on the same port, as is done for example in [11] and [16]. 537 The magic cookie additionally indicates the STUN client is compliant 538 with this specification. The magic cookie is present in all STUN 539 messages -- requests, success responses, error responses and 540 indications. 542 The transaction ID is a 96 bit identifier. STUN transactions are 543 identified by their unique 96-bit transaction ID. For request/ 544 response transactions, the transaction ID is chosen by the STUN 545 client and MUST be unique for each new STUN transaction generated by 546 that STUN client. Any two requests that are not bit-wise identical, 547 and not sent to the same server from the same IP address and port, 548 MUST have a different transaction ID. The transaction ID MUST be 549 uniformly and randomly distributed between 0 and 2**96 - 1. The 550 large range is needed because the transaction ID serves as a form of 551 randomization, helping to prevent replays of previously signed 552 responses from the server. A reponse to the STUN request, whether it 553 be a success or error response, carries the same transaction ID as 554 the request. Indications are also identified by their transaction 555 ID. The value is chosen by the server an MUST be unique for each 556 unique indication generated by the server. Any two requests that are 557 not bit-wise identical, and not sent to the same server from the same 558 IP address and port, MUST have a different transaction ID. The 559 transaction ID MUST be uniformly and randomly distributed between 0 560 and 2**96 - 1. 562 After the STUN header are zero or more attributes. Each attribute is 563 TLV encoded, with a 16 bit type, 16 bit length, and variable value. 564 Each STUN attribute ends on a 32 bit boundary: 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Value .... | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 3: Format of STUN Attributes 576 The Length refers to the length of the actual useful content of the 577 Value portion of the attribute, measured in bytes. Since STUN aligns 578 attributes on 32 bit boundaries, attributes whose content is not a 579 multiple of 4 bytes are padded with 1, 2 or 3 bytes of padding so 580 that they are a multiple of 4 btyes. Such padding is only needed 581 with attributes that take freeform strings, such as USERNAME and 582 PASSWORD. For attributes that contain more structured data, the 583 attributes are constructed to align on 32 bit boundaries. The value 584 in the Length field refers to the length of the Value part of the 585 attribute prior to padding - i.e., the useful content. Consequently, 586 when parsing messages, implementations will need to round up the 587 Length field to the nearest multiple of four in order to find the 588 start of the next attribute. 590 The attribute types defined in this specification are in Section 11 . 592 7. STUN Transactions 594 STUN defines two types of transactions - request/response 595 transactions and indication transactions. 597 7.1. Request/Response Transactions 599 STUN clients are allowed to pipeline STUN requests. That is, a STUN 600 client MAY have multiple outstanding STUN requests with different 601 transaction IDs and not wait for completion of a STUN request/ 602 response exchange before sending another STUN request. 604 When running STUN over UDP it is possible that the STUN request or 605 its response might be dropped by the network. Reliability of STUN 606 request message types is is accomplished through client 607 retransmissions. Clients SHOULD retransmit the request starting with 608 an interval of 100ms, doubling every retransmit until the interval 609 reaches 1.6 seconds. Retransmissions continue with intervals of 1.6 610 seconds until a response is received, or a total of 9 requests have 611 been sent. If no response is received by 1.6 seconds after the last 612 request has been sent, the client SHOULD consider the transaction to 613 have failed. In other words, requests would be sent at times 0ms, 614 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 615 9500ms, the client considers the transaction to have failed if no 616 response has been received. A STUN transaction over UDP is also 617 considered failed if there has been a transport failure of some sort, 618 such as a fatal ICMP error. 620 When running STUN over TCP, TCP is responsible for ensuring delivery. 621 The STUN application SHOULD NOT retransmit STUN requests when running 622 over TCP. If the client has not received a response after 9500ms, it 623 considers the transaction to have failed. 625 Regardless of whether TCP or UDP was used for the transaction, if a 626 failure occurs and the client has other servers it can reach (as a 627 consequence of an SRV query which provides a multiplicity of STUN 628 servers Section 8.1, for example), the client SHOULD create a new 629 request, which is identical to the previous, but has a different 630 transaction ID (and consequently a different MESSAGE INTEGRITY and 631 FINGERPRINT attribute). 633 7.2. Indications 635 Indications are sent from the client to the server, or from the 636 server to the client. Though no indications are used by this 637 specification, they are used by the STUN relay usage [14]. When sent 638 over UDP, there are no retransmissions, and reliability is not 639 provided. When sent over TCP, reliability is provided by TCP. 641 If a data indication solicits a fatal ICMP error, or causes a TCP 642 error, the transaction is considered to have failed. In such a case, 643 the client SHOULD create a new transaction, which is identical to the 644 previous, but has a different transaction ID (and consequently a 645 different MESSAGE INTEGRITY and FINGERPRINT attribute). That request 646 is sent to the next element in the list as specified by RFC2782. 648 8. Client Behavior 650 Client behavior can be broken down into several steps. The first is 651 discovery of the STUN server. The next is obtaining a shared secret. 652 For request/response transactions, the next steps are formulating the 653 request and processing the response. For indication transactions, 654 the next step is formulating the indication. 656 8.1. Discovery 658 Unless stated otherwise by a STUN usage, DNS is used to discover the 659 STUN server following these procedures. 661 The client will be configured with a domain name of the provider of 662 the STUN servers. This domain name is resolved to an IP address and 663 port using the SRV procedures specified in RFC2782 [3]. The 664 mechanism for configuring the STUN client with the domain name to 665 look up is not in scope of this document. 667 The DNS SRV service name depends on the application usage. For the 668 binding usage, the service name is "stun". The protocol can be "udp" 669 for UDP, "tcp" for TCP and "tls" for TLS over TCP. For the short 670 term password application usage, the service name is "stun-pass". 671 The protocol is always "tls" for TLS over TCP. The binding keepalive 672 and connectivity check usages always start with an IP address, so no 673 DNS SRV service names are defined for them. New STUN usages MAY 674 define additional DNS SRV service names. These SHOULD start with 675 "stun". 677 The procedures of RFC 2782 are followed to determine the server to 678 contact. RFC 2782 spells out the details of how a set of SRV records 679 are sorted and then tried. However, RFC2782 only states that the 680 client should "try to connect to the (protocol, address, service)" 681 without giving any details on what happens in the event of failure; 682 those details for STUN are described in Section 8.3.1. 684 A STUN server supporting multiple usages (such as the short term 685 password and binding discovery usage) MAY use the same ports for 686 different usages, as long as ports are not needed to differentiate 687 the usages. Different ports are not needed to differentiate the 688 usages defined in this specification. Different ports SHOULD be used 689 for TCP and TCP/TLS, so that the server can determine whether the 690 first message it will receive after the TCP connection is set up is a 691 STUN message or a TLS message. 693 The default port for STUN requests is 3478, for both TCP and UDP. 694 There is no default port for STUN over TLS. Administrators SHOULD 695 use this port in their SRV records for UDP and TCP, but MAY use 696 others. If no SRV records were found, the client performs an A or 697 AAAA record lookup of the domain name. The result will be a list of 698 IP addresses, each of which can be contacted at the default port 699 using UDP or TCP, independent of the STUN usage. For usages that 700 require TLS, such as the short term password usage, lack of SRV 701 records is equivalent to a failure of the transaction, since the 702 request or indication MUST NOT be sent unless SRV records provided an 703 address and port specifically for TLS. 705 8.2. Obtaining a Shared Secret 707 As discussed in Section 13, there are several attacks possible on 708 STUN systems. Many of these attacks are prevented through integrity 709 protection of requests and responses. To provide that integrity, 710 STUN makes use of a shared secret between client and server which is 711 used as the keying material for the MESSAGE-INTEGRITY attribute in 712 STUN messages. STUN allows for the shared secret to be obtained in 713 any way. The application usage defines the mechanism and required 714 implementation strength for shared secrets. 716 Some usages, such as the connectivity check usage, assume that out of 717 band protocols, such as ICE, are used to obtain the necessary 718 credentials. Other usages, such as binding keepalives, don't use 719 authentication, as it is not required. Others, such as the binding 720 discovery, allows for authentication using either a long term shared 721 secret or a short term shared secret. The latter can be obtained by 722 using the short term password usage to obtain a short term shared 723 secret. 725 Consequently, the STUN usages define rules for obtaining shared 726 secrets prior to sending a request. 728 8.3. Request/Response Transactions 730 8.3.1. Formulating the Request Message 732 The client follows the syntax rules defined in Section 6 and the 733 transmission rules of Section 7. The message type of the MUST be a 734 request type; "Binding Request" or "Shared Secret Request" are the 735 two defined by this document. 737 The client creates a STUN message following the STUN message 738 structure described in Section 6. The client SHOULD add a MESSAGE- 739 INTEGRITY and USERNAME attribute to the Request message if the usage 740 employs authentication. The specific credentials to use are 741 described by the STUN usage, which can specify no credentials, a 742 short term credential, or a long term credential. The procedures for 743 each are: 745 1. If the STUN usage specifies that no credentials are used, the 746 message is sent without MESSAGE-INTEGRITY 748 2. If a short term credential is to be used, the STUN Request or 749 STUN Indication would contain the USERNAME and MESSAGE-INTEGRITY 750 attributes. The message would not contain the NONCE attribute. 751 The key for MESSAGE-INTEGRITY is the password. 753 3. If a long term credential is to be used, the STUN request 754 contains the USERNAME, REALM, and MESSAGE-INTEGRITY attributes. 755 The 16-byte key for MESSAGE-INTEGRITY HMAC is formed by taking 756 the MD5 hash of the result of concatenating the following five 757 fields: (1) The username, with any quotes and trailing nulls 758 removed, (2) A single colon, (3) The realm, with any quotes and 759 trailing nulls removed, (4) A single colon, and (5) The password, 760 with any trailing nulls removed. For example, if the USERNAME 761 field were 'user', the REALM field were '"realm"', and the 762 PASSWORD field were 'pass', then the 16-byte HMAC key would be 763 the result of performing an MD5 hash on the string 'user:realm: 764 pass', or 0x8493fbc53ba582fb4c044c456bdc40eb. 766 This format for the key was chosen so as to enable a common 767 authentication database for SIP, which uses digest authentication 768 as defined in RFC 2617 [7] and STUN, as it is expected that 769 credentials are usually stored in their hashed forms. 771 The NONCE is included in the request only if a short or long term 772 credential is being used, and only if the STUN request is a retry as 773 a consequence of a previous error response which provided the client 774 with a NONCE. 776 For TCP and TLS-over-TCP, the client opens a TCP connection to the 777 server. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be 778 supported at a minimum by implementers when TLS is used with STUN. 779 Implementers MAY also support any other ciphersuite. When it 780 receives the TLS Certificate message, the client SHOULD verify the 781 certificate and inspect the site identified by the certificate. If 782 the certificate is invalid, revoked, or if it does not identify the 783 appropriate party, the client MUST NOT send the STUN message or 784 otherwise proceed with the STUN transaction. The client MUST verify 785 the identity of the server. To do that, it follows the 786 identification procedures defined in Section 3.1 of RFC 2818 [4]. 787 Those procedures assume the client is dereferencing a URI. For 788 purposes of usage with this specification, the client treats the 789 domain name or IP address used in Section 8.1as the host portion of 790 the URI that has been dereferenced. If DNS was not used, the client 791 MUST be configured with a set of authorized domains whose 792 certificates will be accepted. 794 The client MUST include a FINGERPRINT attribute as the last 795 attribute. 797 Next, the client sends the request. For UDP-based requests, 798 reliability is accomplished through client retransmissions, following 799 the procedure in Section 7.1. For TCP (including TLS over TCP), 800 there are no retransmissions. 802 For TCP and TLS over TCP, the client MAY send multiple requests on 803 the connection, and it MAY pipeline requests (that is, it can have 804 multiple requests outstanding at the same time). When using TCP or 805 TLS over TCP, the client SHOULD close the connection as soon as it 806 has received the STUN Response, if it has no plans to send further 807 requests. 809 8.3.2. Processing Responses 811 All responses, whether success responses or error responses, MUST 812 first be authenticated by the client. Authentication is performed by 813 first comparing the Transaction ID of the response to an oustanding 814 request. If there is no match, the client MUST discard the response. 815 Then the client SHOULD check the response for a MESSAGE-INTEGRITY 816 attribute. If not present, and the client placed a MESSAGE-INTEGRITY 817 attribute into the associated request, it MUST discard the response. 818 If MESSAGE-INTEGRITY is present, the client computes the HMAC over 819 the response as described in Section 11.4. The key that is used MUST 820 be same as used to compute the MESSAGE-INTEGRITY attribute in the 821 request. 823 If the computed HMAC matches the one from the response, processing 824 continues. 826 If the response is an Error Response, the client checks the response 827 code from the ERROR-CODE attribute of the response. For a 400 828 response code, the client SHOULD display the reason phrase to the 829 user. For a 420 response code, the client SHOULD retry the request, 830 this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES 831 attribute of the response. 833 If the client receives a 401 response and had not included a MESSAGE- 834 INTEGRITY attribute in the request, it is an indication from the 835 server that credentials are required. If the REALM attribute was 836 present in the response, it is a signal to the client to use a long 837 term shared secret and retry the request. The client SHOULD retry 838 the request, using the username and password associated with the 839 REALM. If the server had provided a nonce in the 401 response, the 840 client SHOULD include the same nonce in the retry. If the REALM 841 attribute was absent in the resposne, it is a signal to the client to 842 use a short term shared secret and retry the request. If the client 843 doesn't have a short term shared secret, it SHOULD use the Shared 844 Secret request to obtain one, and then retry the request with the 845 username and password obtained as a result. If the 401 response had 846 contained a NONCE attribute, that same nonce is included in the 847 retry. 849 If the client receives a 401 response but had included a MESSAGE- 850 INTEGRITY attribute in the request, there has been an unrecoverable 851 error. This shouldn't ever happen, but if it does, the client SHOULD 852 NOT retry the request. 854 If the client receives a 432 response, and the client had omitted the 855 USERNAME from the request but included a MESSAGE-INTEGRITY, the 856 client SHOULD retry the request and include both MESSAGE-INTEGRITY 857 and USERNAME. If the 432 response had contained a NONCE attribute, 858 that same nonce is included in the retry. If the client receives a 859 432 but had included both MESSAGE-INTEGRITY and USERNAME in the 860 request, there has been an unrecoverable error. This shouldn't ever 861 happen, but if it does, the client SHOULD NOT retry the request. 863 If the client receives a 435 response, but had included a NONCE in 864 the request, an unrecoverable error has occurred and the client 865 SHOULD NOT retry. However, if it had omitted the NONCE in the 866 request and received a 435, or it had included the NONCE but received 867 a 438, it is a request from the server to retry using the same 868 credential, but with a different nonce. The client SHOULD retry the 869 request, using the nonce provided in the NONCE attribute of the 435 870 or 438 response. 872 If the client receives a 430 response, it means that the client used 873 a short term credential which has expired. If the client had 874 submitted the request using a short term credential obtained from a 875 Shared Secret request, the client SHOULD generate a new Shared Secret 876 request to obtain a new short term credential, and then retry the 877 request with that credential. Note that the Shared Secret request 878 may or may not go to the same server which generated the 430 879 response; the server that receives the Shared Secret request is 880 determined by the DNS procedures defined above. If a 430 response 881 was received and the client had used a short term credential provided 882 through some other means, the client SHOULD obtain a new short term 883 credential using that mechanism. If the client had not used a short 884 term credential in the request, the 430 error is unrecoverable and 885 the request SHOULD NOT be retried. If the 430 response had contained 886 a NONCE attribute, that same nonce is included in the retry. 888 For a 431 response code, the client SHOULD alert the user, and if a 889 short term credential obtained from a Shared Secret request had been 890 used previously, the client MAY try the request again after obtaining 891 a new short term username and password. If the 431 response had 892 contained a NONCE attribute, that same nonce is included in the 893 retry. 895 If the client receives a 433 response, and the request was a Shared 896 Secret request which was not sent over TLS, the client SHOULD retry 897 the request, and MUST send it using TLS. If this response is 898 received to any other request except for a Shared Secret request, or 899 if the client had sent the Shared Secret request over TLS, it is an 900 unrecoverable error and the client SHOULD NOT retry. As with other 901 error responses, the 433 can contain a NONCE, and if present, that 902 nonce is used in the request retry. 904 If the client receives a 434 response, and had omitted the REALM in 905 the request, but had included MESSAGE-INTEGRITY, it is an indication 906 that, though a short-term credential was used for the request, the 907 server desires the client to use a long term credential. The client 908 SHOULD retry the request using the username and password associated 909 with the REALM. As with other error responses, the 434 can contain a 910 NONCE, and if present, that nonce is used in the request retry. If 911 the 434 was received but the request had contained a REALM, and the 912 REALM in the response differs from the REALM in the request, the 913 client SHOULD retry using the username and password associated with 914 the REALM in the response. If the REALMS were equal, this is an 915 unrecoverable error and the client SHOULD NOT retry. 917 It the client receives a 436 response, it means that the username it 918 provided in the request is unknown. For usages where the username 919 was collectedd from the user, the client SHOULD alert the user. The 920 client SHOULD NOT retry with the same username. 922 For error responses which can contain a NONCE, the client includes 923 the NONCE in a subsequent retry as discussed above. Furthermore, the 924 client SHOULD cache the nonce, and continue using it in subsequent 925 requests sent to the same server, identified by IP address and port. 927 For a 300 response code, the client SHOULD attempt a new transaction 928 to the server indicated in the ALTERNATE-SERVER attribute. This is 929 useful for load balancing requests across a STUN server cluster, when 930 those requests require some amount of resources to process. Though 931 this specification allows the 300 response to be applied to Binding 932 Requests, it is generally not useful to do so, since the work of 933 redirecting a Binding Request is equal to, if not more than, the work 934 of just processing the Binding Request. Consequently, the 300 935 response code is targeted for other usages of STUN, such as the relay 936 usage [14]. 938 For a 500 response code, the client MAY wait several seconds and then 939 retry the request on the same server. Or, if the server was learned 940 through DNS SRV records, the client MAY try the request on a 941 different server. The same username and password MAY be used. For a 942 600 response code, client MUST NOT retry the request on this server, 943 or if the server was learned through DNS, any other server found 944 through the DNS resolution procedures. Unknown response codes 945 between 400 and 499 are treated like a 400, unknown response codes 946 between 500 and 599 are treated like a 500, and unknown response 947 codes between 600 and 699 are treated like a 600. Any response 948 between 100 and 299 MUST result in the cessation of request 949 retransmissions, but otherwise is discarded. 951 Responses containing unknown optional attributes (greater than 952 0x7FFF) MUST be ignored by the STUN client. Responses containing 953 unknown mandatory attributions (less than or equal to 0x7FFF) MUST be 954 discarded and considered immediately as a failed transaction. 956 It is also possible for an IPv4 host to receive a XOR-MAPPED-ADDRESS 957 or MAPPED-ADDRESS containing an IPv6 address, or for an IPv6 host to 958 receive a XOR-MAPPED-ADDRESS or MAPPED-ADDRESS containing an IPv4 959 address. Clients MUST be prepared for this case. 961 The processing of other attributes in the response, such as the 962 mapped address (present in the XOR-MAPPED-ADDRESS attribute or 963 MAPPED-ADDRESS attribute) depends on the STUN usage. 965 8.4. Indication Transactions 967 This section applies to client and server behavior for sending an 968 Indication message. 970 The client or server follows the syntax rules defined in Section 6 971 and the transmission rules of Section 7. The message type MUST be 972 one of the Indication message types; none are defined by this 973 document. 975 Indication messages cannot be challenged or rejected. Consequently, 976 they cannot be authenticated using long term credentials. If a STUN 977 usage specifies that authentication is needed for an indication 978 message, it can only be done using a short term credential. In that 979 case, the client or server MUST add a MESSAGE-INTEGRITY and USERNAME 980 attribute to the Request message. The key for MESSAGE-INTEGRITY is 981 the password. 983 The client or server MUST include a FINGERPRINT attribute as the last 984 attribute of any Indication message. 986 Typically, indication messages are sent to the same IP address and 987 port, or over the same TCP connections as a previous request message. 988 However, a usage can specify that indication messages are sent based 989 on a DNS query, in which case the discovery procedures in Section 8.1 990 are followed, along with the TCP/TLS connection establishment 991 procedures defined in Section 8.3.1. 993 Indication message types are not sent reliably, do not elicit a 994 response from the server, and are not retransmitted. 996 For TCP and TLS over TCP, the client or server MAY send multiple 997 indications on the connection. By definition, since indications to 998 not generate a response, they can be pipelined on the connection. 999 For clients, the connection is closed once it determines it has no 1000 further messages to send to the server. Servers do not normally 1001 close TCP connections. 1003 9. Server Behavior 1005 As with clients, server behavior depends on whether it is a request/ 1006 response transaction or indication. 1008 9.1. Request/Response Transactions 1010 The server behavior for receiving request message types is described 1011 in this section. 1013 9.1.1. Receive Request Message 1015 A STUN server MUST be prepared to receive request messages on the IP 1016 address and UDP or TCP port that will be discovered by the STUN 1017 client when the STUN client follows its discovery procedures 1018 described in Section 8.1. Depending on the usage, the STUN server 1019 will listen for incoming UDP STUN messages, incoming TCP STUN 1020 messages, or incoming TLS exchanges followed by TCP STUN messages. 1022 When a STUN request is received, the server determines the usage. 1023 The usages describe how the STUN server makes this determination. 1025 Based on the usage, the server determines whether the request 1026 requires any authentication and message integrity checks. It can 1027 require none, short-term credential based authentication, or long- 1028 term credential authentication. 1030 If authentication is required, the server checks for the presence of 1031 the MESSAGE-INTEGRITY attribute. If not present, the server 1032 generates an error response with an ERROR-CODE attribute and a 1033 response code of 401. If the server wishes the client to use a short 1034 term credential, the REALM is omitted from the response. If the 1035 server wishes the client to use a long term credential, the REALM is 1036 included in the response containing a realm from which the username 1037 and password are scoped [7]. When the REALM is present in the 1038 response, the server MUST include a NONCE attribute in the response. 1039 The nonce includes a random value that the server wishes the client 1040 to reflect back in a subsequent request (and therefore include in the 1041 message integrity computation). When the REALM is absent in the 1042 response, the server MAY include a NONCE in the response if it wishes 1043 to use nonces along with short-term shared secrets. However, there 1044 is little reason to do so, since the short-term password is, by 1045 definition, short-term, and thus additional temporal scoping through 1046 the nonce is not needed. 1048 If the MESSAGE-INTEGRITY attribute was present, the server checks for 1049 the existence of the USERNAME attribute. If it was not present, the 1050 server MUST generate an error response. The error response MUST 1051 include an ERROR-CODE attribute with a response code of 432. If the 1052 server is using a long term credential for authentication, the 1053 response MUST include a REALM and a NONCE. If the server is using a 1054 short-term credential, it MUST NOT include a REALM in the response 1055 and MAY include a NONCE. 1057 If the server is using long term credentials for authentication, and 1058 the request contained the MESSAGE-INTEGRITY and USERNAME attributes, 1059 the server checks for the existence of the REALM attribute. If the 1060 attribute is not present, the server MUST generate an error response. 1062 That error response MUST include an ERROR-CODE attribute with 1063 response code of 434. That error response MUST also include a NONCE 1064 and a REALM attribute. 1066 If the REALM attribute was present and the server is using a long 1067 term credential for authentication, the server checks for the 1068 existence of the NONCE attribute. If the NONCE attribute is not 1069 present, the server MUST generate an error response. That error 1070 response MUST include an ERROR-CODE attribute with a response code of 1071 435. That error response MUST include a NONCE attribute and a REALM 1072 attribute. If the NONCE was absent and the server is authenticating 1073 with short term credentials, the server MAY generate an error 1074 response with an ERROR-CODE attribute with a response code of 435. 1075 This response MUST included a NONCE. If the NONCE was present in the 1076 request, but the server has determined it is stale, the server MUST 1077 generate an error response with an ERROR-CODE attribute with a 1078 response code of 438. 1080 Next, if the server is authenticating the request, it checks for the 1081 presence of the USERNAME attribute. If absent, the server generates 1082 an error response with an ERROR-CDE attribute with a response code of 1083 432. If the server is authenticating using long term credentials, it 1084 MUST include a REALM and NONCE in the response. If the server is 1085 authenticating with short term credentials, it MUST NOT include a 1086 REALM and MAY include a NONCE. 1088 If the server is authenticating the request with a short term 1089 credential, it checks the value of the USERNAME field. If the 1090 USERNAME was previously valid but has expired, the server generates 1091 an error response with an ERROR-CODE attribute with a response code 1092 of 430. This error response MAY include a NONCE. If the server is 1093 authenticating with either short or long term credentials, it 1094 determines whether the USERNAME contains a known entity, and in the 1095 case of a long-term credential, known within the realm of the REALM 1096 attribute of the request. If the USERNAME is unknown, the server 1097 generates an error response with an ERROR-CODE attribute with a 1098 response code of 436. For authentication using long-term 1099 credentials, that error response MUST include a NONCE attribute and a 1100 REALM attribute. For authentication using short-term credentials, it 1101 MAY include a NONCE but MUST NOT include a REALM. 1103 At this point, if the server is doing authentication, the request 1104 contains everything needed for that purpose. The server computes the 1105 HMAC over the request as described in Section 11.4. The key depends 1106 on the credential. For short-term credentials, it equals the 1107 password associated with the username. For long term credentials, it 1108 is computed as described in Section 8.3.1. 1110 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 1111 attribute in the request, the server MUST generate an error response 1112 with an ERROR-CODE attribute with a response code of 431. If long 1113 term credentials are being used for authentication, this response 1114 MUST include a NONCE attribute and a REALM attribute. If short term 1115 credentials are being used, it MAY include a NONCE and MUST NOT 1116 include a REALM. 1118 At this point, the request has been authentication checked and 1119 integrity verified. 1121 Next, the server MUST check for any mantadory attributes in the 1122 request (values less than or equal to 0x7fff) which it does not 1123 understand. If it encounters any, the server MUST generate an error 1124 response, and it MUST include an ERROR-CODE attribute with a 420 1125 response code. Any attributes that are known, but are not supposed 1126 to be present in a message (MAPPED-ADDRESS in a request, for example) 1127 MUST be ignored. 1129 9.1.2. Constructing the Response 1131 To construct the STUN Response the STUN server follows the message 1132 structure described in Section 6. The server then copies the 1133 Transaction ID from the Request to the Response. If the STUN 1134 response is a success response, the STUN server adds 0x100 to the 1135 Message Type of the request. If the STUN response is a success 1136 response, the STUN server adds 0x110 to the Message Type of the 1137 request. 1139 The attributes that get added to the response depend on the type of 1140 response. See Figure 4 for a summary. 1142 If the response is a type which can carry either MAPPED-ADDRESS or 1143 XOR-MAPPED-ADDRESS (the Binding Response as defined in this 1144 specification meets that criteria), the server examines the magic 1145 cookie in the STUN header. If it has the value 0x2112A442, it 1146 indicates that the client supports this version of the specification. 1147 The server MUST insert a XOR-MAPPED-ADDRESS into the response, 1148 carrying the exclusive-or of the source IP address and port from the 1149 request. If the magic cookie did not have this value, it indicates 1150 that the client supports the previous version of this specification. 1151 The server MUST insert a MAPPED-ADDRESS attribute into the response, 1152 carrying the souce IP address and port from the request. Insertion 1153 of either XOR-MAPPED-ADDRESS or MAPPED-ADDRESS happens regardless of 1154 the transport protocol used for the request. 1156 XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their encoding 1157 of the IP address and port. The former, as implied by the name, 1158 encodes the IP address and port by exclusive-or'ing them with the 1159 magic cookie. The latter encodes them directly in binary. RFC 3489 1160 originally specified only MAPPED-ADDRESS. However, deployment 1161 experience found that some NATs rewrite the 32-bit binary payloads 1162 containing the NAT's public IP address, such as STUN's MAPPED-ADDRESS 1163 attribute, in the well-meaning but misguided attempt at providing a 1164 generic ALG function. Such behavior interferes with the operation of 1165 STUN and also causes failure of STUN's message integrity checking. 1167 The server SHOULD include a SERVER attribute in all responses, 1168 indicating the identity of the server generating the response. This 1169 is useful for diagnostic purposes. 1171 The server MUST include a FINGERPRINT attribute as the last attribute 1172 of any Indication message. 1174 In cases where the server cannot handle the request, due to 1175 exhaustion of resources, the server MAY generate a 300 response with 1176 an ALTERNATE-SERVER attribute. This attribute identifies an 1177 alternate server which can service the requests. It is not expected 1178 that 300 responses or this attribute would be used by the requests 1179 defined in this specification. 1181 9.1.3. Sending the Response 1183 All UDP response messages are sent to the IP address and port the 1184 associated Binding Request came from, and sent from the IP address 1185 and port the Binding Request was sent to. All TCP or TLS over TCP 1186 responses messages are sent on the TCP connections that the request 1187 arrived on. 1189 9.2. Indication Transactions 1191 Indication messages cause the server to change its state. Indication 1192 message types to not cause the server to send a response message. 1194 A STUN server MUST be prepared to receive indication messages on the 1195 IP address and UDP or TCP port that will be discovered by the STUN 1196 client when the STUN client follows its discovery procedures 1197 described in Section 8.1. Depending on the usage, the STUN server 1198 will listen for incoming UDP STUN messages, incoming TCP STUN 1199 messages, or incoming TLS exchanges followed by TCP STUN messages. 1201 When a STUN indication is received, the server determines the usage. 1202 The usages describe how the STUN server makes this determination. 1204 Based on the usage, the server determines whether the indication 1205 requires any authentication and message integrity checks. It can 1206 require none or short-term credential based authentication. If 1207 short-term credentials are utilized, the server follows the same 1208 procedures as defined in Section 9.1.1, but if those procedures 1209 require transmission of an error response, the server MUST instead 1210 silently discard the indication. 1212 Once authenticated (if authentication was in use), the processing of 1213 the indication message depends on the message type. This 1214 specification doesn't define any indication messages. 1216 10. Demultiplexing of STUN and Application Traffic 1218 In both the connectivity check and binding refresh usages, STUN 1219 traffic is multiplexed on the same IP address and port as application 1220 traffic, such as RTP. In order to apply the processing described in 1221 this specification, STUN messages must first be separated from the 1222 application packets. This disambiguation is done identically for 1223 requests and responses of all types. 1225 First, all STUN messages start with two bits equal to zero. If STUN 1226 is being multiplexed with application traffic where it is known that 1227 the topmost two bits are never zeroes, the presence of these two 1228 zeroes signals STUN traffic. 1230 If this mechanism doesn't suffice, the magic cookie can be used. All 1231 STUN messages have the value 0x2112A442 as the second 32 bit word. 1232 If the application traffic can not have this value as the second 32 1233 bit word, then any packets with this value are STUN packets. Even if 1234 the application packet can have this value (for example, in cases 1235 where the application packets contain random binary data), there is 1236 only a one in 2^32 chance that an application packet will have a 1237 value of 0x2112A442 in its second 32 bit word. If this probability 1238 is deemed sufficiently small for the application at hand (for 1239 example, it is considered adequate for Voice over IP applications), 1240 then any packet with this value in its second 32 bit word is 1241 processed as a STUN packet. 1243 However, a mis-classification of 1 in 2^32 may still be too high for 1244 some usages of STUN. Consequently, all STUN messages contain a 1245 FINGERPRINT attribute. This is a cryptographic hash over the 1246 message, covering everything prior to the attribute. This attribute 1247 is different from MESSAGE-INTEGRITY. The latter uses a keyed HMAC, 1248 and thus requires a shared secret. FINGERPRINT does not use a 1249 password, and can be computed just by examining the STUN message. 1250 Thus, if a packet appears to be a STUN message because it has a value 1251 of 0x2112A442 in its second 32 bit word, a client or server then 1252 assumes the message is a STUN message, and computes the value for the 1253 fingerprint. It then looks for the FINGERPRINT attribute in the 1254 message, and if the value equals the computed value, the message is 1255 considered to be a STUN message. If not, it is considered to be an 1256 application packet 1258 11. STUN Attributes 1260 To allow future revisions of this specification to add new attributes 1261 if needed, the attribute space is divided into optional and mandatory 1262 ones. Attributes with values greater than 0x7fff are optional, which 1263 means that the message can be processed by the client or server even 1264 though the attribute is not understood. Attributes with values less 1265 than or equal to 0x7fff are mandatory to understand, which means that 1266 the client or server cannot successfully process the message unless 1267 it understands the attribute. 1269 The values of the message attributes are enumerated in Section 15. 1271 The following figure indicates which attributes are present in which 1272 messages. An M indicates that inclusion of the attribute in the 1273 message is mandatory, O means its optional, C means it's conditional 1274 based on some other aspect of the message, and - means that the 1275 attribute is not applicable to that message type. 1277 Error 1278 Attribute Request Response Response Indication 1279 _______________________________________________________ 1280 MAPPED-ADDRESS - C - - 1281 USERNAME O - - O 1282 PASSWORD - C - - 1283 MESSAGE-INTEGRITY O O O O 1284 ERROR-CODE - - M - 1285 ALTERNATE-SERVER - - C - 1286 REALM C - C - 1287 NONCE C - C - 1288 UNKNOWN-ATTRIBUTES - - C - 1289 XOR-MAPPED-ADDRESS - C - - 1290 SERVER - O O O 1291 REFRESH-INTERVAL - O - - 1292 FINGERPRINT M M M M 1294 Figure 4: Mandatory Attributes and Message Types 1296 11.1. MAPPED-ADDRESS 1298 The MAPPED-ADDRESS attribute indicates the mapped IP address and 1299 port. It consists of an eight bit address family, and a sixteen bit 1300 port, followed by a fixed length value representing the IP address. 1301 If the address family is IPv4, the address is 32 bits. If the 1302 address family is IPv6, the address is 128 bits. 1304 The format of the MAPPED-ADDRESS attribute is: 1306 0 1 2 3 1307 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 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 |x x x x x x x x| Family | Port | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Address (variable) 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 Figure 5: Format of MAPPED-ADDRESS attribute 1316 The address family can take on the following values: 1318 0x01:IPv4 1319 0x02:IPv6 1321 The port is a network byte ordered representation of the port the 1322 request arrived from. 1324 The first 8 bits of the MAPPED-ADDRESS are ignored for the purposes 1325 of aligning parameters on natural 32 bit boundaries. 1327 11.2. USERNAME 1329 The USERNAME attribute is used for message integrity. It identifies 1330 the shared secret used in the message integrity check. Consequently, 1331 the USERNAME MUST be included in any request that contains the 1332 MESSAGE-INTEGRITY attribute. 1334 The USERNAME is also always present in a Shared Secret Response, 1335 along with the PASSWORD, which informs a client of a short term 1336 password. 1338 The value of USERNAME is a variable length opaque value. Note that, 1339 as described above, if the USERNAME is not a multiple of four bytes 1340 it is padded for encoding into the STUN message, in which case the 1341 attribute length represents the length of the USERNAME prior to 1342 padding. 1344 11.3. PASSWORD 1346 If the message type is Shared Secret Response it MUST include the 1347 PASSWORD attribute. 1349 The value of PASSWORD is a variable length opaque value. The 1350 password returned in the Shared Secret Response is used as the HMAC 1351 in the MESSAGE-INTEGRITY attribute of a subsequent STUN transaction. 1352 Note that, as described above, if the USERNAME is not a multiple of 1353 four bytes it is padded for encoding into the STUN message, in which 1354 case the attribute length represents the length of the USERNAME prior 1355 to padding. 1357 11.4. MESSAGE-INTEGRITY 1359 The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [8] of the STUN 1360 message. The MESSAGE-INTEGRITY attribute can be present in any STUN 1361 message type. Since it uses the SHA1 hash, the HMAC will be 20 1362 bytes. The text used as input to HMAC is the STUN message, including 1363 the header, up to and including the attribute preceding the MESSAGE- 1364 INTEGRITY attribute. That text is then padded with zeroes so as to 1365 be a multiple of 64 bytes. As a result, the MESSAGE-INTEGRITY 1366 attribute is generally the next to last attribute in any STUN 1367 message. With the exception of the FINGERPRINT attribute, which 1368 appears after MESSAGE-INTEGRITY, elements MUST ignore all other 1369 attributes which follow MESSAGE-INTEGRITY. 1371 The key used as input to HMAC depends on the STUN usage and the 1372 shared secret mechanism. 1374 11.5. FINGERPRINT 1376 The FINGERPRINT attribute is present in all STUN messages. It is 1377 computed as a SHA1 hash of the STUN message up to (but excluding) the 1378 FINGERPRINT attribute itself. The value of the attribute is the 1379 actual binary output of the SHA-1 function. The FINGERPRINT 1380 attribute MUST be the last attribute in the message. 1382 11.6. ERROR-CODE 1384 The ERROR-CODE attribute is present in the Binding Error Response and 1385 Shared Secret Error Response. It is a numeric value in the range of 1386 100 to 699 plus a textual reason phrase encoded in UTF-8, and is 1387 consistent in its code assignments and semantics with SIP [9] and 1388 HTTP [10]. The reason phrase is meant for user consumption, and can 1389 be anything appropriate for the response code. Recommended reason 1390 phrases for the defined response codes are presented below. 1392 To facilitate processing, the class of the error code (the hundreds 1393 digit) is encoded separately from the rest of the code. 1395 0 1 2 3 1396 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 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | 0 |Class| Number | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Reason Phrase (variable) .. 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 The class represents the hundreds digit of the response code. The 1404 value MUST be between 1 and 6. The number represents the response 1405 code modulo 100, and its value MUST be between 0 and 99. 1407 If the reason phrase has a length that is not a multiple of four 1408 bytes, it is padded for encoding into the STUN message, in which case 1409 the attribute length represents the length of the entire ERROR-CODE 1410 attribute (including the reason phrase) prior to padding. 1412 The following response codes, along with their recommended reason 1413 phrases (in brackets) are defined at this time: 1415 300 (Try Alternate): The client should contact an alternate server 1416 for this request. 1418 400 (Bad Request): The request was malformed. The client should not 1419 retry the request without modification from the previous 1420 attempt. 1422 401 (Unauthorized): The request did not contain a MESSAGE-INTEGRITY 1423 attribute. 1425 420 (Unknown Attribute): The server did not understand a mandatory 1426 attribute in the request. 1428 430 (Stale Credentials): The request did contain a MESSAGE-INTEGRITY 1429 attribute, but it used a shared secret that has expired. The 1430 client should obtain a new shared secret and try again. 1432 431 (Integrity Check Failure): The request contained a MESSAGE- 1433 INTEGRITY attribute, but the HMAC failed verification. This 1434 could be a sign of a potential attack, or client implementation 1435 error. 1437 432 (Missing Username): The request contained a MESSAGE-INTEGRITY 1438 attribute, but not a USERNAME attribute. Both USERNAME and 1439 MESSAGE-INTEGRITY must be present for integrity checks. 1441 433 (Use TLS): The Shared Secret request has to be sent over TLS, 1442 but was not received over TLS. 1444 434 (Missing Realm): The REALM attribute was not present in the 1445 request. 1447 435 (Missing Nonce): The NONCE attribute was not present in the 1448 request. 1450 436 (Unknown Username): The USERNAME supplied in the request is not 1451 known or is not known to the server. 1453 438 (Stale Nonce): The NONCE attribute was present in the request 1454 but wasn't valid. 1456 500 (Server Error): The server has suffered a temporary error. The 1457 client should try again. 1459 600 (Global Failure): The server is refusing to fulfill the request. 1460 The client should not retry. 1462 11.7. REALM 1464 The REALM attribute is present in requests and responses. It 1465 contains text which meets the grammar for "realm" as described in RFC 1466 3261 [9], and will thus contain a quoted string (including the 1467 quotes). 1469 Presence of the REALM attribute in a request indicates that long-term 1470 credentials are being used for authentication. Presence in certain 1471 error responses indicates that the server wishes the client to use a 1472 long-term credential for authentication. 1474 11.8. NONCE 1476 The NONCE attribute is present in requests and in error responses. 1477 It contains a sequence of qdtext or quoted-pair, which are defined in 1478 RFC 3261 [9]. See RFC 2617 [7] for guidance on selection of nonce 1479 values in a server. 1481 11.9. UNKNOWN-ATTRIBUTES 1483 The UNKNOWN-ATTRIBUTES attribute is present only in an error response 1484 when the response code in the ERROR-CODE attribute is 420. 1486 The attribute contains a list of 16 bit values, each of which 1487 represents an attribute type that was not understood by the server. 1488 If the number of unknown attributes is an odd number, one of the 1489 attributes MUST be repeated in the list, so that the total length of 1490 the list is a multiple of 4 bytes. 1492 0 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Attribute 1 Type | Attribute 2 Type | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Attribute 3 Type | Attribute 4 Type ... 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Figure 8: Format of UNKNOWN-ATTRIBUTES attribute 1502 11.10. XOR-MAPPED-ADDRESS 1504 The XOR-MAPPED-ADDRESS attribute is present in responses. It 1505 provides the same information that would present in the MAPPED- 1506 ADDRESS attribute but because the NAT's public IP address is 1507 obfuscated through the XOR function, STUN messages are able to pass 1508 through NATs which would otherwise interfere with STUN. 1510 This attribute MUST always be present in a Binding Response and may 1511 be used in other responses as well. Usages defining new requests and 1512 responses should specify if XOR-MAPPED-ADDRESS is applicable to their 1513 responses. 1515 The format of the XOR-MAPPED-ADDRESS is: 1517 0 1 2 3 1518 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 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 |x x x x x x x x| Family | X-Port | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | X-Address (Variable) 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 Figure 9: Format of XOR-MAPPED-ADDRESS Attribute 1527 The Family represents the IP address family, and is encoded 1528 identically to the Family in MAPPED-ADDRESS. 1530 X-Port is the mapped port, exclusive or'd with most significant 16 1531 bits of the magic cookie. If the IP address family is IPv4, 1532 X-Address is the mapped IP address exclusive or'd with the magic 1533 cookie. If the IP address family is IPv6, the X-Address is the 1534 mapped IP address exclusively or'ed with the magic cookie and the 96- 1535 bit transaction ID. 1537 For example, using the "^" character to indicate exclusive or, if the 1538 IP address is 192.168.1.1 (0xc0a80101) and the port is 5555 (0x15B3), 1539 the X-Port would be 0x15B3 ^ 0x2112 = 0x34A1, and the X-Address would 1540 be 0xc0a80101 ^ 0x2112A442 = 0xe1baa543. 1542 11.11. SERVER 1544 The server attribute contains a textual description of the software 1545 being used by the server, including manufacturer and version number. 1546 The attribute has no impact on operation of the protocol, and serves 1547 only as a tool for diagnostic and debugging purposes. The value of 1548 SERVER is variable length. If the value of SERVER is not a multiple 1549 of four bytes, it is padded for encoding into the STUN message, in 1550 which case the attribute length represents the length of the USERNAME 1551 prior to padding. 1553 11.12. ALTERNATE-SERVER 1555 The alternate server represents an alternate IP address and port for 1556 a different STUN server to try. It is encoded in the same way as 1557 MAPPED-ADDRESS. 1559 This attribute is MUST only appear in an error response. 1561 11.13. REFRESH-INTERVAL 1563 The REFRESH-INTERVAL indicates the number of milliseconds that the 1564 server suggests the client should use between refreshes of the NAT 1565 bindings between the client and server. Even though the server may 1566 not know the binding lifetimes in intervening NATs, this attribute 1567 serves as a useful configuration mechanism for suggesting a value for 1568 use by the client. Furthermore, when the NAT Keepalive usage is 1569 being used, the server may become overloaded with Binding Requests 1570 that are being used for keepalives. The REFRESH-INTERVAL provies a 1571 mechanism for the server to gradually reduce the load on itself by 1572 pushing back on the client. 1574 REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and 1575 represents an interval measured in millseconds. It can be present in 1576 Binding Responses. 1578 12. STUN Usages 1579 STUN is a simple request/response protocol that provides a useful 1580 capability in several situations. In this section, different usages 1581 of STUN are described. Each usage may differ in how STUN servers are 1582 discovered, when the STUN requests are sent, what message types are 1583 used, what message attributes are used, and how authentication is 1584 performed. 1586 This specification defines the STUN usages for binding discovery 1587 (Section 12.1), connectivity check (Section 12.2), NAT keepalives 1588 (Section 12.3) and short-term password (Section 12.4). 1590 New STUN usages may be defined by other standards-track documents. 1591 New STUN usages MUST describe their applicability, client discovery 1592 of the STUN server, how the server determines the usage, new message 1593 types (requests or indications), new message attributes, new error 1594 response codes, and new client and server procedures. 1596 12.1. Binding Discovery 1598 The previous version of this specification, RFC3489 [13], described 1599 only this binding discovery usage. 1601 12.1.1. Applicability 1603 Binding discovery is used to learn reflexive addresses from servers 1604 on the network, generally the public Internet. That is, it is used 1605 by a client to determine its dynamically-bound 'public' IP address 1606 and UDP port that is assigned by a NAT between a STUN client and a 1607 STUN server. This address and port will be present in the mapped 1608 address of the STUN Binding Response. 1610 The mapped address present in the binding response can be used by 1611 clients to facilitate traversal of NATs for many applications. NAT 1612 traversal is problematic for applications which require a client to 1613 insert an IP address and port into a message, to which subsequent 1614 messages will be delivered by other entities in a network. Normally, 1615 the client would insert the IP address and port from a local 1616 interface into the message. However, if the client is behind a NAT, 1617 this local interface will be a private address. Clients within other 1618 address realms will not be able to send messages to that address. 1620 An example of a such an application is SIP, which requires a client 1621 to include IP address and port information in several places, 1622 including the Session Description Protocol (SDP [17]) body carried by 1623 SIP. The IP address and port present in the SDP is used for receipt 1624 of media. 1626 To use STUN as a technique for traversal of SIP and other protocols, 1627 when the client wishes to send a protocol message, it figures out the 1628 places in the protocol data unit where it is supposed to insert its 1629 own IP address along with a port. Instead of directly using a port 1630 allocated from a local interface, the client allocates a port from 1631 the local interface, and from that port, generates a STUN Binding 1632 Request. The mapped address in the Binding Response (XOR-MAPPED- 1633 ADDRESS or MAPPED-ADDRESS) provides the client with an alternative IP 1634 address and port which it can then include in the protocol payload. 1635 This IP address and port may be within a different address family 1636 than the local interfaces used by the client. This is not an error 1637 condition. In such a case, the client would use the learned IP 1638 address and port as if the client was a host with an interface within 1639 that address family. 1641 In the case of SIP, to populate the SDP appropriately, a client would 1642 generate two STUN Binding Request messages at the time a call is 1643 initiated or answered. One is used to obtain the IP address and port 1644 for RTP, and the other, for the Real Time Control Protocol 1645 (RTCP)[15]. The client might also need to use STUN to obtain IP 1646 addresses and ports for usage in other parts of the SIP message. The 1647 detailed usage of STUN to facilitate SIP NAT traversal is outside the 1648 scope of this specification. 1650 As discussed above, the addresses learned by STUN may not be usable 1651 with all entities with whom a client might wish to communicate. The 1652 way in which this problem is handled depends on the application 1653 protocol. The ideal solution is for a protocol to allow a client to 1654 include a multiplicity of addresses and ports in the PDU. One of 1655 those can be the address and port determined from STUN, and the 1656 others can include addresses and ports learned from other techniques. 1657 The application protocol would then provide a means for dynamically 1658 detecting which one works. An example of such an an approach is 1659 Interactive Connectivity Establishment (ICE [11]). 1661 12.1.2. Client Discovery of Server 1663 Clients SHOULD be configured with a domain name for a STUN server to 1664 use. In cases where the client has no explicit configuration 1665 mechanism for STUN, but knows the domain of its service provider, the 1666 client SHOULD use that domain (in the case of SIP, this would be the 1667 domain from their Address-of-Record). The discovery mechanisms 1668 defined in Section 8.1 are then applied to that domain name. 1670 12.1.3. Server Determination of Usage 1672 It is anticipated that servers would advertise a specific port in the 1673 DNS for the Binding Discovery usage. Thus, when a request arrives at 1674 that particular port, the server knows that the binding usage is in 1675 use. This fact is only needed for purposes of determining the 1676 authentication and message integrity mechanism to apply. 1678 12.1.4. New Requests or Indications 1680 This usage does not define any new message types. 1682 12.1.5. New Attributes 1684 This usage does not define any new message attributes. 1686 12.1.6. New Error Response Codes 1688 This usage does not define any new error response codes. 1690 12.1.7. Client Procedures 1692 The binding discovery is utilized by a client just prior to 1693 generating an application PDU that requires the client to include its 1694 IP address and port. The client MAY first obtain a short term 1695 credential using the short term password STUN usage. The credential 1696 that is obtained is then using in Binding Request messages. A 1697 Binding Request message is generated for each distinct IP address and 1698 port that the client requires to formulate the application PDU. 1700 12.1.8. Server Procedures 1702 It is RECOMMENDED that servers utilize short term credentials, 1703 obtained by the client from a Shared Secret request, for 1704 authentication and message integrity. Consequently, if a Binding 1705 Request is generated without a short term credential, the server 1706 SHOULD challenge for one. 1708 12.1.9. Security Considerations for Binding Discovery 1710 There are no security considerations for this usage beyond those 1711 described in Section 13. 1713 12.2. Connectivity Check 1715 12.2.1. Applicability 1717 This STUN usage primarily provides a connectivity check to a peer 1718 discovered through rendezvous protocols. The usage presumes that 1719 some other mechanism, such as ICE [11] has been used allow two peer 1720 agents to exchange IP addresses and ports. The agents would like to 1721 initiate direct communications with each other, using those IP 1722 addresses and ports. However, it is not known which IP addresses and 1723 ports will actually work for direct exchange of communications, due 1724 to NAT, firewall and other network connectivity issues. 1725 Consequently, each agent uses a STUN Binding Request from each of 1726 their transport addresses to each of the transport addresses of their 1727 peers. This check serves numerous purposes. Firstly, if a response 1728 is received to a Binding Request, an agent knows that that particular 1729 5-tuple (the transport address that the Binding Request was sent to, 1730 along with the one it was sent from) are viable for direct 1731 communciations. Secondly, the mapped address from the Binding 1732 Response tells the agent its reflexive address towards its peer, 1733 which may be another candidate for receipt of communications. 1734 Finally, the connectivity checks can keep NAT bindings in intervening 1735 NATs active. 1737 It is fundamental to this STUN usage that the addresses and ports 1738 used for direct communications are the same ones used for the Binding 1739 Requests and responses. Consequently, it will be necessary to 1740 demultiplex STUN traffic from whatever the application data traffic 1741 is. This demultiplexing is done using the magic cookie along with 1742 the FINGERPRINT attribute. 1744 Because the connectivity check usage is always used in conjunction 1745 with some kind of rendezvous protocol, it is assumed that the 1746 rendezvous protocol provides the exchange of a short term credential. 1747 This credential is then used for authentication and message integrity 1748 of the STUN Binding Requests and Responses. 1750 The username and password exchanged in the rendezvous protocol is 1751 valid for the duration of the connection being checked. 1753 12.2.2. Client Discovery of Server 1755 The client does not follow the general procedure in Section 8.1. 1756 Instead, the client discovers the STUN server's IP address and port 1757 through a rendezvous protocol. Note that the STUN server is a 1758 logical entity in this usage, and it will be running on the exact 1759 same IP address and port as is used for actual communications. 1761 12.2.3. Server Determination of Usage 1763 The server is aware of this usage because it signalsed this port 1764 through the rendezvous protocol. Any STUN packets received on this 1765 port will be for the connectivity check usage. 1767 12.2.4. New Requests or Indications 1769 This usage does not define any new message types. 1771 12.2.5. New Attributes 1773 This usage does not define any new message attributes. 1775 12.2.6. New Error Response Codes 1777 This usage does not define any new error response codes. 1779 12.2.7. Client Procedures 1781 A client will generate a connectivity check based on the procedures 1782 defined in the rendezvous protocol that uses this usage. Generally 1783 this will be done after an exchange of IP addresses and ports has 1784 occurred between the two clients, at which point connectivity checks 1785 will begin. 1787 Clients MUST include the FINGERPRINT attribute, to aid in 1788 disambiguation of STUN and application traffic. Clients MUST used a 1789 short term credential obtained through the rendezvous protocol. The 1790 specific structure and format of the username and password are 1791 defined by the rendezvous protocol. Receipt of any non-recoverable 1792 STUN error is an indication that there is no connectivity to that IP 1793 address and port. 1795 12.2.8. Server Procedures 1797 In this usage, the short-term password is valid as long as the UDP 1798 port is listening for STUN packets. For example when used with ICE, 1799 the short-term password would be valid as long as the RTP session 1800 (which multiplexes STUN and RTP) is active. 1802 12.2.9. Security Considerations for Connectivity Check 1804 The username and password, which are used for STUN's message 1805 integrity, are exchanged in the rendezvous protocol. Failure to 1806 encrypt and integrity protect the rendezvous protocol is equivalent 1807 in risk to using STUN without message integrity. 1809 12.3. NAT Keepalives 1811 12.3.1. Applicability 1813 In this STUN usage, a client is connected to a server for a 1814 particular application protocol (for example, a SIP proxy server). 1815 The connection is long-lived, allowing for asynchronous messaging 1816 from the server to the client. The client is connected to the server 1817 either using TCP, in which case there is a long-lived TCP connection 1818 from the client to the server, or using UDP, in which case the server 1819 stores the source IP address and port of a message from a client 1820 (such as SIP REGISTER), and sends messages to the client using that 1821 IP address and port. 1823 Since the connection between the client and server is very-long 1824 lived, the bindings established by that connection need to be 1825 maintained in any intervening NATs. Rather than implement expensive 1826 application-layer keepalives, the keepalives can be accomplished 1827 using STUN Binding Requests. The client will periodically sending a 1828 Binding Request to the server, using the same IP address and ports 1829 used for the application protocol. These Binding Requests are 1830 demultiplexed at the server using the magic cookie and possibly 1831 FINGERPRINT. The response from the server informs the client that 1832 the server is still alive. The STUN message also keeps the binding 1833 active in intervening NATs. The client can also examine the mapped 1834 address in the Binding Response. If it has changed, the client can 1835 re-initiate application layer procedures to inform the server of its 1836 new IP address and port. 1838 12.3.2. Client Discovery of Server 1840 In this usage, the STUN server and the application protocol are using 1841 the same fixed port. While the multiplexing of two applications on 1842 the same port is similar to the connectivity check (Section 12.2) 1843 usage, this usage is differs as the server's port is fixed and the 1844 server's port isn't communicated using a rendezvous protocol. 1846 12.3.3. Server Determination of Usage 1848 The server multiplexes both STUN and its application protocol on the 1849 same port. The server knows it is has this usage because the URI 1850 that gets resolved to this port indicates the server supports this 1851 multiplexing. 1853 12.3.4. New Requests or Indications 1855 This usage does not define any new message types. 1857 12.3.5. New Attributes 1859 This usage does not define any new message attributes. 1861 12.3.6. New Error Response Codes 1863 This usage does not define any new error response codes. 1865 12.3.7. Client Procedures 1867 If the STUN Response indicates the client's mapped address has 1868 changed from the client's expected mapped address, the client SHOULD 1869 inform other applications of its new mapped address. For example, a 1870 SIP client should send a new registration message indicating the new 1871 mapped address. 1873 The client SHOULD NOT include a MESSAGE-INTEGRITY attribute, since 1874 authentication is not used with this STUN usage. 1876 12.3.8. Server Procedures 1878 The server MUST NOT authenticate the client or look for a MESSAGE- 1879 INTEGRITY attribute. Authentication is not used with this STUN 1880 usage. 1882 12.3.9. Security Considerations for NAT Keepalives 1884 This STUN usage does not employ message integrity or authentication 1885 of any sort. This is because the client never actually uses the 1886 mapped address from the STUN response. It merely treats a change in 1887 that address as a hint that the client should re-apply application 1888 layer procedures for connection establishment and registration. 1890 An attacker could attempt to inject faked responses, or modify 1891 responses in transit. Such an attack would require the attacker to 1892 be on-path in order to determine the transaction ID. In the worse 1893 case, the attack would cause the client to see a change in IP address 1894 or port, and then perform an application layer re-registration. Such 1895 a re-registration would not use the IP address and port obtained from 1896 the Binding Response. Thus, the worst that the attacker can do is 1897 cause the client to re-register every half minute or so, when it 1898 otherwise wouldn't need to. Given the difficulty in launching this 1899 attack (it requires the attacker to be on-path and to disrupt the 1900 actual response from the server) compared to the benefit, there is 1901 little motivation for authentication or integrity mechanisms. 1903 12.4. Short-Term Password 1905 In order to ensure interoperability, this usage describes a TLS-based 1906 mechanism to obtain a short-term credential. The usage makes use of 1907 the Shared Secret Request and Response messages. It is defined as a 1908 separate usage in order to allow it to run on a separate port, and to 1909 allow it to be more easily separated from the different STUN usages, 1910 only some of which require this mechanism. 1912 12.4.1. Applicability 1914 To thwart some on-path attacks described in Section 13, it is 1915 necessary for the STUN client and STUN server to integrity protect 1916 the information they exchange over UDP. In the absence of a long- 1917 term secret (password) that is shared between them, a short-term 1918 password can be obtained using the usage described in this section. 1920 The username and password returned in the STUN Shared Secret Response 1921 are valid for use in subsequent STUN transactions for nine (9) 1922 minutes with any hosts that have the same SRV Priority value as 1923 discovered via Section 12.4.2. The username and password obtained 1924 with this usage are used as the USERNAME and in the HMAC for the 1925 MESSAGE-INTEGRITY in a subsequent STUN message, respectively. 1927 12.4.2. Client Discovery of Server 1929 The client follows the procedures in Section 8.1. The SRV protocol 1930 is "tls" and the service name "stun-pass". 1932 For example a client would look up "_stun-pass._tls.example.com" in 1933 DNS. 1935 12.4.3. Server Determination of Usage 1937 The server advertises this port in the DNS as capable of receiving 1938 TLS over TCP connections, along with the Shared Secret messages that 1939 run over it. The server MAY also advertise this same port in DNS for 1940 other TLS over TCP usages if the server is capable of multiplexing 1941 those different usages. For example, the server could advertise the 1942 short-term password and binding discovery usages on the same TLS/TCP 1943 port. 1945 12.4.4. New Requests or Indications 1947 The message type Shared Secret Request and its associated Shared 1948 Secret Response and Shared Secret Error Response are defined in this 1949 section. Their values are enumerated in Section 15. 1951 The following figure indicates which attributes are present in the 1952 Shared Secret Request, Response, and Error Response. An M indicates 1953 that inclusion of the attribute in the message is mandatory, O means 1954 its optional, C means it's conditional based on some other aspect of 1955 the message, and - means that the attribute is not applicable to that 1956 message type. Attributes not listed are not applicable to Shared 1957 Secret Request, Response, or Error Response. 1959 Shared Shared Shared 1960 Secret Secret Secret 1961 Attribute Request Response Error 1962 Response 1963 ____________________________________________________________________ 1964 USERNAME O M - 1965 PASSWORD - M - 1966 MESSAGE-INTEGRITY O O O 1967 ERROR-CODE - - M 1968 ALTERNATE-SERVER - - C 1969 UNKNOWN-ATTRIBUTES - - C 1970 SERVER - O O 1971 REALM C - C 1972 NONCE C - C 1974 The Shared Secret requests, like other STUN requests, can be 1975 authenticated. However, since its purpose is to obtain a short-term 1976 credential, the Shared Secret request itself cannot be authenticated 1977 with a short-term credential. However, it can be authenticated with 1978 a long-term credential. 1980 12.4.5. New Attributes 1982 No new attributes are defined by this usage. 1984 12.4.6. New Error Response Codes 1986 This usage defines the 433 error response. Only the MESSAGE- 1987 INTEGRITY, ERROR-CODE and SERVER attributes are applicable to this 1988 response. 1990 12.4.7. Client Procedures 1992 Shared Secret requests are formed like other STUN requests, with the 1993 following additions. Clients MUST NOT use a short-term credential 1994 with a Shared Secret request. They SHOULD send the request with no 1995 credentials (omitting MESSAGE-INTEGRITY and USERNAME). 1997 Processing of the Shared Secret response follows that of any other 1998 STUN response. Note that clients MUST be prepared to be challenged 1999 for a long-term credential. 2001 If the response was a Shared Secret Response, the it will contain a 2002 short lived username and password, encoded in the USERNAME and 2003 PASSWORD attributes, respectively. A client SHOULD use these 2004 credentials whenever short term credentials are needed for any server 2005 discovered using the same domain name as was used to discover the one 2006 which returned those credentials. For example, if a client used a 2007 domain name of example.com, it would have looked up _stun- 2008 pass._tls.example.com in DNS, found a server, and sent a Shared 2009 Secret request that provided a credential to the client. The client 2010 would use this credential with a server discovered by looking up 2011 _stun._udp.example.com in the DNS. 2013 If the response was a Shared Secret Error Response, and ERROR-CODE 2014 attribute was present with a response code of 433, and the client had 2015 not sent the request over TLS, the client SHOULD establish a TLS 2016 connection to the server and retry the request over that connection. 2017 If the client had used TLS, this error response is unrecoverable and 2018 the client SHOULD NOT retry. 2020 12.4.8. Server Procedures 2022 The procedures for general processing of STUN requests apply to 2023 Shared Secret requests. Servers MAY challenge the client for a long- 2024 term credential if one was not provided in a request. However, they 2025 MUST NOT challenge the request for a short-term credential. 2027 If the Shared Secret Request did not arrive over a TLS connection, 2028 the server MUST generate a Shared Secret Error response with an 2029 ERROR-CODE attribute that has a response code of 433. 2031 If the request is valid and authenticated (assuming the server is 2032 performing authentication), the server MUST create a short term 2033 credential for the user. This credential consists of a username and 2034 password. The credentials MUST be valid for a duration of at least 2035 nine minutes, and SHOULD NOT be valid for a duration of longer than 2036 thirty minutes. The username MUST be distinct, with extremely high 2037 probabilities, from all usernames that have been handed out across 2038 all servers that are returned from DNS SRV queries for the same 2039 domain name. Extremely high probability means that the likelihood of 2040 collision SHOULD be better than 1 in 2**64. The password for each 2041 username MUST be cryptographically random with at least 128 bits of 2042 entropy. 2044 12.4.9. Security Considerations for Short-Term Password 2046 The security considerations in Section 13 do not apply to the Shared 2047 Secret request and response, since these messages do not make use of 2048 mapped addresses, which is the primary source of security 2049 consideration discussed there. Rather, shared secret requests are 2050 used to obtain short term credentials that are used in the 2051 authentication of other messages. 2053 Because the Shared Secret response itself carries a credential, in 2054 the form of a username and password, it must be sent encrypted. For 2055 this reason, STUN servers MUST reject any Shared Secret request that 2056 has not arrived over a TLS connection. 2058 Malicious clients could generate a multiplicity of Shared Secret 2059 requests, each of which causes the server to allocate shared secrets, 2060 each of which might consume memory and processing resources. If 2061 shared secret requests are not being authenticated, this leads to a 2062 possible denial-of-service attack. Indeed, even if the requestor is 2063 authenticated, attacks are still possible. 2065 To prevent being swamped with traffic, a STUN server SHOULD limit the 2066 number of simultaneous TLS connections it will hold open by dropping 2067 an existing connection when a new connection request arrives (based 2068 on an Least Recently Used (LRU) policy, for example). 2070 Similarly, servers SHOULD allocate only a small number of shared 2071 secrets to a host with a particular source IP address and port. 2072 Requests from the same IP address and port which exceed this limit 2073 SHOULD be rejected with a 600 response. Servers SHOULD also limit 2074 the total number of shared secrets they will provide at a time across 2075 all clients, based on the number of users and expected loads during 2076 normal peak usage. If a Shared Secret request arrives and the server 2077 has exceeded its limit, it SHOULD reject the request with a 500 2078 response. 2080 Furthermore, for servers which are not authenticating shared secret 2081 requests, it is RECOMMENDED that short-term credentials be 2082 constructed in a way such that they do not require memory or disk to 2083 store. 2085 This can be done by intelligently computing the username and 2086 password. One approach is to construct the USERNAME as: 2088 USERNAME = 2090 Where prefix is some random text string (different for each shared 2091 secret request), rounded-time is the current time modulo 20 minutes, 2092 clientIP is the source IP address where the Shared Secret Request 2093 came from, and hmac is an HMAC [13] over the prefix, rounded-time, 2094 and client IP, using a server private key. 2096 The password is then computed as: 2098 password = 2100 With this structure, the username itself, which will be present in 2101 the Binding Request, contains the source IP address where the Shared 2102 Secret Request came from. That allows the server to meet the 2103 requirements specified in Section 8.1 for constructing the REFLECTED- 2104 FROM attribute. The server can verify that the username was not 2105 tampered with, using the hmac present in the username. 2107 13. Security Considerations 2109 Attacks on STUN systems vary depending on the usage. The short term 2110 password usage is quite different from the other usages defined here, 2111 and its security considerations are unique to it and discussed as 2112 part of the usage definition. However, all of the other usages are 2113 very similar, and share a similar set of security considerations as a 2114 consequence of their usage of the mapped address from STUN Binding 2115 Responses. Consequently, these security considerations apply to 2116 usage of the mapped address. 2118 13.1. Attacks on STUN 2120 Generally speaking, attacks on STUN can be classified into denial of 2121 service attacks and eavesdropping attacks. Denial of service attacks 2122 can be launched against a STUN server itself, or against other 2123 elements using the STUN protocol. The attacks of greater interest 2124 are those in which the STUN server and client are used to launch 2125 denial of service (DoS) attacks against other entities, including the 2126 client itself. Many of the attacks require the attacker to generate 2127 a response to a legitimate STUN request, in order to provide the 2128 client with a faked mapped address. The attacks that can be launched 2129 using such a technique include: 2131 13.1.1. Attack I: DDoS Against a Target 2133 In this case, the attacker provides a large number of clients with 2134 the same faked mapped address that points to the intended target. 2135 This will trick all the STUN clients into thinking that their 2136 addresses are equal to that of the target. The clients then hand out 2137 that address in order to receive traffic on it (for example, in SIP 2138 or H.323 messages). However, all of that traffic becomes focused at 2139 the intended target. The attack can provide substantial 2140 amplification, especially when used with clients that are using STUN 2141 to enable multimedia applications. 2143 13.1.2. Attack II: Silencing a Client 2145 In this attack, the attacker seeks to deny a client access to 2146 services enabled by STUN (for example, a client using STUN to enable 2147 SIP-based multimedia traffic). To do that, the attacker provides 2148 that client with a faked mapped address. The mapped address it 2149 provides is an IP address that routes to nowhere. As a result, the 2150 client won't receive any of the packets it expects to receive when it 2151 hands out the mapped address. This exploitation is not very 2152 interesting for the attacker. It impacts a single client, which is 2153 frequently not the desired target. Moreover, any attacker that can 2154 mount the attack could also deny service to the client by other 2155 means, such as preventing the client from receiving any response from 2156 the STUN server, or even a DHCP server. 2158 13.1.3. Attack III: Assuming the Identity of a Client 2160 This attack is similar to attack II. However, the faked mapped 2161 address points to the attacker themself. This allows the attacker to 2162 receive traffic which was destined for the client. 2164 13.1.4. Attack IV: Eavesdropping 2166 In this attack, the attacker forces the client to use a mapped 2167 address that routes to itself. It then forwards any packets it 2168 receives to the client. This attack would allow the attacker to 2169 observe all packets sent to the client. However, in order to launch 2170 the attack, the attacker must have already been able to observe 2171 packets from the client to the STUN server. In most cases (such as 2172 when the attack is launched from an access network), this means that 2173 the attacker could already observe packets sent to the client. This 2174 attack is, as a result, only useful for observing traffic by 2175 attackers on the path from the client to the STUN server, but not 2176 generally on the path of packets being routed towards the client. 2178 13.2. Launching the Attacks 2180 It is important to note that attacks of this nature (injecting 2181 responses with fake mapped addresses) require that the attacker be 2182 capable of eavesdropping requests sent from the client to the server 2183 (or to act as a man in the middle for such attacks). This is because 2184 STUN requests contain a transaction identifier, selected by the 2185 client, which is random with 96 bits of entropy. The server echoes 2186 this value in the response, and the client ignores any responses that 2187 don't have a matching transaction ID. Therefore, in order for an 2188 attacker to provide a faked response that is accepted by the client, 2189 the attacker needs to know the transaction ID of the request. The 2190 large amount of randomness, combined with the need to know when the 2191 client sends a request and the IP address and UDP ports used for that 2192 request, precludes attacks that involve guessing the transaction ID. 2194 Since all of the above attacks rely on this one primitive - injecting 2195 a response with a faked mapped address - preventing the attacks is 2196 accomplished by preventing this one operation. To prevent it, we 2197 need to consider the various ways in which it can be accomplished. 2198 There are several: 2200 13.2.1. Approach I: Compromise a Legitimate STUN Server 2202 In this attack, the attacker compromises a legitimate STUN server 2203 through a virus or Trojan horse. Presumably, this would allow the 2204 attacker to take over the STUN server, and control the types of 2205 responses it generates. Compromise of a STUN server can also lead to 2206 discovery of open ports. Knowledge of an open port creates an 2207 opportunity for DoS attacks on those ports (or DDoS attacks if the 2208 traversed NAT is a full cone NAT). Discovering open ports is already 2209 fairly trivial using port probing, so this does not represent a major 2210 threat. 2212 13.2.2. Approach II: DNS Attacks 2214 STUN servers are discovered using DNS SRV records. If an attacker 2215 can compromise the DNS, it can inject fake records which map a domain 2216 name to the IP address of a STUN server run by the attacker. This 2217 will allow it to inject fake responses to launch any of the attacks 2218 above. Clearly, this attack is only applicable for usages which 2219 discover servers through DNS. 2221 13.2.3. Approach III: Rogue Router or NAT 2223 Rather than compromise the STUN server, an attacker can cause a STUN 2224 server to generate responses with the wrong mapped address by 2225 compromising a router or NAT on the path from the client to the STUN 2226 server. When the STUN request passes through the rogue router or 2227 NAT, it rewrites the source address of the packet to be that of the 2228 desired mapped address. This address cannot be arbitrary. If the 2229 attacker is on the public Internet (that is, there are no NATs 2230 between it and the STUN server), and the attacker doesn't modify the 2231 STUN request, the address has to have the property that packets sent 2232 from the STUN server to that address would route through the 2233 compromised router. This is because the STUN server will send the 2234 responses back to the source address of the request. With a modified 2235 source address, the only way they can reach the client is if the 2236 compromised router directs them there. 2238 If the attacker is on a private network (that is, there are NATs 2239 between it and the STUN server), the attacker will not be able to 2240 force the server to generate arbitrary mapped addresses in responses. 2241 They will only be able force the STUN server to generate mapped 2242 addresses which route to the private network. This is because the 2243 NAT between the attacker and the STUN server will rewrite the source 2244 address of the STUN request, mapping it to a public address that 2245 routes to the private network. Because of this, the attacker can 2246 only force the server to generate faked mapped addresses that route 2247 to the private network. Unfortunately, it is possible that a low 2248 quality NAT would be willing to map an allocated public address to 2249 another public address (as opposed to an internal private address), 2250 in which case the attacker could forge the source address in a STUN 2251 request to be an arbitrary public address. This kind of behavior 2252 from NATs does appear to be rare. 2254 13.2.4. Approach IV: Man in the Middle 2256 As an alternative to approach III (Section 13.2.3), if the attacker 2257 can place an element on the path from the client to the server, the 2258 element can act as a man-in-the-middle. In that case, it can 2259 intercept a STUN request, and generate a STUN response directly with 2260 any desired value of the mapped address field. Alternatively, it can 2261 forward the STUN request to the server (after potential 2262 modification), receive the response, and forward it to the client. 2263 When forwarding the request and response, this attack is subject to 2264 the same limitations on the mapped address described in Approach III 2265 (Section 13.2.3). 2267 13.2.5. Approach V: Response Injection Plus DoS 2269 In this approach, the attacker does not need to be a MitM (as in 2270 approaches III and IV). Rather, it only needs to be able to 2271 eavesdrop onto a network segment that carries STUN requests. This is 2272 easily done in multiple access networks such as ethernet or 2273 unprotected 802.11. To inject the fake response, the attacker 2274 listens on the network for a STUN request. When it sees one, it 2275 simultaneously launches a DoS attack on the STUN server, and 2276 generates its own STUN response with the desired mapped address 2277 value. The STUN response generated by the attacker will reach the 2278 client, and the DoS attack against the server is aimed at preventing 2279 the legitimate response from the server from reaching the client. 2280 Arguably, the attacker can do without the DoS attack on the server, 2281 so long as the faked response beats the real response back to the 2282 client, and the client uses the first response, and ignores the 2283 second (even though it's different). 2285 13.2.6. Approach VI: Duplication 2287 This approach is similar to approach V (Section 13.2.5). The 2288 attacker listens on the network for a STUN request. When it sees it, 2289 it generates its own STUN request towards the server. This STUN 2290 request is identical to the one it saw, but with a spoofed source IP 2291 address. The spoofed address is equal to the one that the attacker 2292 desires to have placed in the mapped address of the STUN response. 2293 In fact, the attacker generates a flood of such packets. The STUN 2294 server will receive the one original request, plus a flood of 2295 duplicate fake ones. It generates responses to all of them. If the 2296 flood is sufficiently large for the responses to congest routers or 2297 some other equipment, there is a reasonable probability that the one 2298 real response is lost (along with many of the faked ones), but the 2299 net result is that only the faked responses are received by the STUN 2300 client. These responses are all identical and all contain the mapped 2301 address that the attacker wanted the client to use. 2303 The flood of duplicate packets is not needed (that is, only one faked 2304 request is sent), so long as the faked response beats the real 2305 response back to the client, and the client uses the first response, 2306 and ignores the second (even though it's different). 2308 Note that, in this approach, launching a DoS attack against the STUN 2309 server or the IP network, to prevent the valid response from being 2310 sent or received, is problematic. The attacker needs the STUN server 2311 to be available to handle its own request. Due to the periodic 2312 retransmissions of the request from the client, this leaves a very 2313 tiny window of opportunity. The attacker must start the DoS attack 2314 immediately after the actual request from the client, causing the 2315 correct response to be discarded, and then cease the DoS attack in 2316 order to send its own request, all before the next retransmission 2317 from the client. Due to the close spacing of the retransmits (100ms 2318 to a few seconds), this is very difficult to do. 2320 Besides DoS attacks, there may be other ways to prevent the actual 2321 request from the client from reaching the server. Layer 2 2322 manipulations, for example, might be able to accomplish it. 2324 Fortunately, this approach is subject to the same limitations 2325 documented in Approach III (Section 13.2.3), which limit the range of 2326 mapped addresses the attacker can cause the STUN server to generate. 2328 13.3. Countermeasures 2330 STUN provides mechanisms to counter the approaches described above, 2331 and additional, non-STUN techniques can be used as well. 2333 First off, it is RECOMMENDED that networks with STUN clients 2334 implement ingress source filtering [6]. This is particularly 2335 important for the NATs themselves. As Section 13.2.3 explains, NATs 2336 which do not perform this check can be used as "reflectors" in DDoS 2337 attacks. Most NATs do perform this check as a default mode of 2338 operation. We strongly advise people that purchase NATs to ensure 2339 that this capability is present and enabled. 2341 Secondly, for usages where the STUN server is not co-located with 2342 some kind of application (such as the binding discovery usage), it is 2343 RECOMMENDED that STUN servers be run on hosts dedicated to STUN, with 2344 all UDP and TCP ports disabled except for the STUN ports. This is to 2345 prevent viruses and Trojan horses from infecting STUN servers, in 2346 order to prevent their compromise. This helps mitigate Approach I 2347 (Section 13.2.1). 2349 Thirdly, to prevent the DNS attack of Section 13.2.2, Section 8.2 2350 recommends that the client verify the credentials provided by the 2351 server with the name used in the DNS lookup. 2353 Finally, all of the attacks above rely on the client taking the 2354 mapped address it learned from STUN, and using it in application 2355 layer protocols. If encryption and message integrity are provided 2356 within those protocols, the eavesdropping and identity assumption 2357 attacks can be prevented. As such, applications that make use of 2358 STUN addresses in application protocols SHOULD use integrity and 2359 encryption, even if a SHOULD level strength is not specified for that 2360 protocol. For example, multimedia applications using STUN addresses 2361 to receive RTP traffic would use secure RTP [21]. 2363 The above three techniques are non-STUN mechanisms. STUN itself 2364 provides several countermeasures. 2366 Approaches IV (Section 13.2.4), when generating the response locally, 2367 and V (Section 13.2.5) require an attacker to generate a faked 2368 response. A faked response must match the 96-bit transaction ID of 2369 the request. The attack further prevented by using the message 2370 integrity mechanism provided in STUN, described in Section 11.4. 2372 Approaches III (Section 13.2.3), IV (Section 13.2.4), when using the 2373 relaying technique, and VI (Section 13.2.6), however, are not 2374 preventable through server signatures. These three approaches are 2375 functional when the attacker modifies nothing but the source address 2376 of the STUN request. Sadly, this is the one thing that cannot be 2377 protected through cryptographic means, as this is the change that 2378 STUN itself is seeking to detect and report. It is therefore an 2379 inherent weakness in NAT, and not fixable in STUN. 2381 13.4. Residual Threats 2383 None of the countermeasures listed above can prevent the attacks 2384 described in Section 13.2.3 if the attacker is in the appropriate 2385 network paths. Specifically, consider the case in which the attacker 2386 wishes to convince client C that it has address V. The attacker needs 2387 to have a network element on the path between A and the server (in 2388 order to modify the request) and on the path between the server and V 2389 so that it can forward the response to C. Furthermore, if there is a 2390 NAT between the attacker and the server, V must also be behind the 2391 same NAT. In such a situation, the attacker can either gain access 2392 to all the application-layer traffic or mount the DDOS attack 2393 described in Section 13.1.1. Note that any host which exists in the 2394 correct topological relationship can be DDOSed. It need not be using 2395 STUN. 2397 14. IAB Considerations 2399 The IAB has studied the problem of "Unilateral Self Address Fixing" 2400 (UNSAF), which is the general process by which a client attempts to 2401 determine its address in another realm on the other side of a NAT 2402 through a collaborative protocol reflection mechanism (RFC3424 [22]). 2403 STUN is an example of a protocol that performs this type of function 2404 for the binding discovery and connectivity check usages. The IAB has 2405 mandated that any protocols developed for this purpose document a 2406 specific set of considerations. This section meets those 2407 requirements for those two usages. 2409 14.1. Problem Definition 2411 From RFC3424 [22], any UNSAF proposal must provide: 2413 Precise definition of a specific, limited-scope problem that is to 2414 be solved with the UNSAF proposal. A short term fix should not be 2415 generalized to solve other problems; this is why "short term fixes 2416 usually aren't". 2418 The specific problem being solved by STUN is to provide a means for a 2419 client to obtain a mapped address which can be used for the receipt 2420 of incoming application packets. 2422 14.2. Exit Strategy 2424 From RFC3424 [22], any UNSAF proposal must provide: 2426 Description of an exit strategy/transition plan. The better short 2427 term fixes are the ones that will naturally see less and less use 2428 as the appropriate technology is deployed. 2430 STUN by itself does not provide an exit strategy. This is provided 2431 by techniques, such as Interactive Connectivity Establishment (ICE 2432 [11]), which allow a client to determine whether addresses learned 2433 from STUN are needed, or whether other addresses, such as the one on 2434 the local interface, will work when communicating with another host. 2435 With such a detection technique, as a client finds that the addresses 2436 provided by STUN are never used, STUN queries can cease to be made, 2437 thus allowing them to phase out. 2439 14.3. Brittleness Introduced by STUN 2441 From RFC3424 [22], any UNSAF proposal must provide: 2443 Discussion of specific issues that may render systems more 2444 "brittle". For example, approaches that involve using data at 2445 multiple network layers create more dependencies, increase 2446 debugging challenges, and make it harder to transition. 2448 STUN introduces brittleness into the system in several ways: 2450 o Transport addresses discovered by STUN in the Binding Discovery 2451 usage will only be useful for receiving packets from a peer if the 2452 NAT does not have address or address and port dependent mapping 2453 properties. When this usage is used in isolation, this makes STUN 2454 brittle, since its effectiveness depends on the type of NAT. This 2455 brittleness is eliminated when the Binding Discovery usage is used 2456 in concert with mechanisms which can verify the transport address 2457 and use others if it doesn't work. ICE is an example of such a 2458 mechanism. 2460 o Transport addresses discovered by STUN in the Binding Discovery 2461 usage will only be useful for receive packets from a peer if the 2462 STUN server subtends the address realm of the peer. For example, 2463 consider client A and B, both of which have residential NAT 2464 devices. Both devices connect them to their cable operators, but 2465 both clients have different providers. Each provider has a NAT in 2466 front of their entire network, connecting it to the public 2467 Internet. If the STUN server used by A is in A's cable operator's 2468 network, an address obtained by it will not be usable by B. The 2469 STUN server must be in the network which is a common ancestor to 2470 both - in this case, the public Internet. When this usage is used 2471 in isolation, this makes STUN brittle, since its effectiveness 2472 depends on the topological placement of the STUN server. This 2473 brittleness is eliminated when the Binding Discovery usage is used 2474 in concert with mechanisms which can verify the transport address 2475 and use others if it doesn't work. ICE is an example of such a 2476 mechanism. 2478 o The bindings allocated from the NAT need to be continuously 2479 refreshed. Since the timeouts for these bindings is very 2480 implementation specific, the refresh interval cannot easily be 2481 determined. When the binding is not being actively used to 2482 receive traffic, but to wait for an incoming message, the binding 2483 refresh will needlessly consume network bandwidth. 2485 o The use of the STUN server in the Binding Discovery usage as an 2486 additional network element introduces another point of potential 2487 security attack. These attacks are largely prevented by the 2488 security measures provided by STUN, but not entirely. 2490 o The use of the STUN server as an additional network element 2491 introduces another point of failure. If the client cannot locate 2492 a STUN server, or if the server should be unavailable due to 2493 failure, the application cannot function. 2495 o The use of STUN to discover address bindings may result in an 2496 increase in latency for applications. 2498 o Transport addresses discovered by STUN in the Binding Discovery 2499 usage will only be useful for receive packets from a peer behind 2500 the same NAT if the STUN server supports hairpinning [12]. When 2501 this usage is used in isolation, this makes STUN brittle, since 2502 its effectiveness depends on the topological placement of the STUN 2503 server. This brittleness is eliminated when the Binding Discovery 2504 usage is used in concert with mechanisms which can verify the 2505 transport address and use others if it doesn't work. ICE is an 2506 example of such a mechanism. 2508 o Most significantly, STUN introduces potential security threats 2509 which cannot be eliminated through cryptographic means. These 2510 security problems are described fully in Section 13. 2512 14.4. Requirements for a Long Term Solution 2514 From RFC3424 [22], any UNSAF proposal must provide: 2516 Identify requirements for longer term, sound technical solutions 2517 -- contribute to the process of finding the right longer term 2518 solution. 2520 Our experience with STUN has led to the following requirements for a 2521 long term solution to the NAT problem: 2523 o Requests for bindings and control of other resources in a NAT need 2524 to be explicit. Much of the brittleness in STUN derives from its 2525 guessing at the parameters of the NAT, rather than telling the NAT 2526 what parameters to use, or knowing what parameters the NAT will 2527 use. 2529 o Control needs to be in-band. There are far too many scenarios in 2530 which the client will not know about the location of middleboxes 2531 ahead of time. Instead, control of such boxes needs to occur in- 2532 band, traveling along the same path as the data will itself 2533 travel. This guarantees that the right set of middleboxes are 2534 controlled. 2536 o Control needs to be limited. Users will need to communicate 2537 through NATs which are outside of their administrative control. 2538 In order for providers to be willing to deploy NATs which can be 2539 controlled by users in different domains, the scope of such 2540 controls needs to be extremely limited - typically, allocating a 2541 binding to reach the address where the control packets are coming 2542 from. 2544 o Simplicity is Paramount. The control protocol will need to be 2545 implement in very simple clients. The servers will need to 2546 support extremely high loads. The protocol will need to be 2547 extremely robust, being the precursor to a host of application 2548 protocols. As such, simplicity is key. 2550 14.5. Issues with Existing NAPT Boxes 2552 From RFC3424 [22], any UNSAF proposal must provide: 2554 Discussion of the impact of the noted practical issues with 2555 existing, deployed NA[P]Ts and experience reports. 2557 Originally, RFC 3489 was developed as a standalone solution for NAT 2558 traversal for several types of applications, including VoIP. 2559 However, practical experience found that the limitations of its usage 2560 in isolation made it impractical as a complete solution. There were 2561 too many NATs which didn't support hairpinning or which had address 2562 and port dependent mapping properties. 2564 Consequently, STUN was revised to produce this specification, which 2565 turns STUN into a tool that is used as part of a broader solution. 2566 For multimedia communciations protocols, this broader solution is 2567 ICE. ICE uses the binding discovery and connectivity check usages 2568 together. When done this way, ICE eliminates almost all of the 2569 brittleness and issues found with RFC 3489 alone. 2571 15. IANA Considerations 2573 IANA is hereby requsted to create two new registries STUN Message 2574 Types and STUN Attributes. IANA must assign the following values to 2575 both registeries before publication of this document as an RFC. New 2576 values for both STUN Message Type and STUN Attributes are assigned 2577 through the IETF consensus process via RFCs approved by the IESG 2578 [23]. 2580 15.1. STUN Message Type Registry 2582 For STUN Message Types that are request message types, they must be 2583 registered including associated Response message types and Error 2584 Response message types, and those responses must have values that are 2585 0x100 and 0x110 higher than their respective Request values. 2587 For STUN Message Types that are Indication message types, no 2588 associated restriction applies. As the message type field is only 14 2589 bits the range of valid values is 0x001 through 0x3FFF. 2591 The initial STUN Message Types are: 2593 0x0001:Binding Request 2594 0x0101:Binding Response 2595 0x0111:Binding Error Response 2596 0x0002:Shared Secret Request 2597 0x0102:Shared Secret Response 2598 0x0112:Shared Secret Error Response 2600 15.2. STUN Attribute Registry 2602 STUN attributes values above 0x7FFF are considered optional 2603 attributes; attributes equal to 0x7FFF or below are considered 2604 mandatory attributes. The STUN client and STUN server process 2605 optional and mandatory attributes differently. IANA should assign 2606 values based on the RFC consensus process. 2608 The initial STUN Attributes are: 2610 0x0001: MAPPED-ADDRESS 2611 0x0006: USERNAME 2612 0x0007: PASSWORD 2613 0x0008: MESSAGE-INTEGRITY 2614 0x0009: ERROR-CODE 2615 0x000A: UNKNOWN-ATTRIBUTES 2616 0x0014: REALM 2617 0x0015: NONCE 2618 0x0020: XOR-MAPPED-ADDRESS 2619 0x0023: FINGERPRINT 2620 0x8022: SERVER 2621 0x8023: ALTERNATE-SERVER 2622 0x8024: REFRESH-INTERVAL 2624 16. Changes Since RFC 3489 2626 This specification updates RFC3489 [13]. This specification differs 2627 from RFC3489 in the following ways: 2629 o Removed the usage of STUN for NAT type detection and binding 2630 lifetime discovery. These techniques have proven overly brittle 2631 due to wider variations in the types of NAT devices than described 2632 in this document. Removed the RESPONSE-ADDRESS, CHANGED-ADDRESS, 2633 CHANGE-REQUEST, SOURCE-ADDRESS, and REFLECTED-FROM attributes. 2635 o Removed the STUN example that centered around the separation of 2636 the control and media planes. Instead, provided more information 2637 on using STUN with protocols. 2639 o Added a fixed 32-bit magic cookie and reduced length of 2640 transaction ID by 32 bits. The magic cookie begins at the same 2641 offset as the original transaction ID. 2643 o Added the XOR-MAPPED-ADDRESS attribute, which is included in 2644 Binding Responses if the magic cookie is present in the request. 2645 Otherwise the RFC3489 behavior is retained (that is, Binding 2646 Response includes MAPPED-ADDRESS). See discussion in XOR-MAPPED- 2647 ADDRESS regarding this change. 2649 o Explicitly point out that the most significant two bits of STUN 2650 are 0b00, allowing easy differentiation with RTP packets when used 2651 with ICE. 2653 o Added support for IPv6. Made it clear that an IPv4 client could 2654 get a v6 mapped address, and vice-a-versa. 2656 o Added long-term credential-based authentication. 2658 o Added the SERVER, REALM, NONCE, and ALTERNATE-SERVER attributes. 2660 o Removed recommendation to continue listening for STUN Responses 2661 for 10 seconds in an attempt to recognize an attack. 2663 o Introduced the concept of STUN usages and defined four usages - 2664 Binding Discovery, Connectivity Check, NAT Keepalive, and Short 2665 term password. 2667 17. Acknowledgements 2669 The authors would like to thank Cedric Aoun, Pete Cordell, Cullen 2670 Jennings, Bob Penfield and Chris Sullivan for their comments, and 2671 Baruch Sterman and Alan Hawrylyshen for initial implementations. 2672 Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning 2673 Schulzrinne for IESG and IAB input on this work. 2675 18. References 2677 18.1. Normative References 2679 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2680 Levels", BCP 14, RFC 2119, March 1997. 2682 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 2684 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2685 specifying the location of services (DNS SRV)", RFC 2782, 2686 February 2000. 2688 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2690 [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2691 RFC 2246, January 1999. 2693 [6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 2694 Denial of Service Attacks which employ IP Source Address 2695 Spoofing", BCP 38, RFC 2827, May 2000. 2697 [7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2698 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 2700 Basic and Digest Access Authentication", RFC 2617, June 1999. 2702 18.2. Informational References 2704 [8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2705 for Message Authentication", RFC 2104, February 1997. 2707 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2708 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2709 Session Initiation Protocol", RFC 3261, June 2002. 2711 [10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2712 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2713 HTTP/1.1", RFC 2616, June 1999. 2715 [11] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 2716 Methodology for Network Address Translator (NAT) Traversal for 2717 Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in 2718 progress), March 2006. 2720 [12] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 2721 Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress), 2722 June 2006. 2724 [13] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 2725 - Simple Traversal of User Datagram Protocol (UDP) Through 2726 Network Address Translators (NATs)", RFC 3489, March 2003. 2728 [14] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 2729 of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in 2730 progress), March 2006. 2732 [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2733 "RTP: A Transport Protocol for Real-Time Applications", 2734 RFC 3550, July 2003. 2736 [16] Jennings, C. and R. Mahy, "Managing Client Initiated 2737 Connections in the Session Initiation Protocol (SIP)", 2738 draft-ietf-sip-outbound-03 (work in progress), March 2006. 2740 [17] Handley, M., "SDP: Session Description Protocol", 2741 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 2743 [18] Senie, D., "Network Address Translator (NAT)-Friendly 2744 Application Design Guidelines", RFC 3235, January 2002. 2746 [19] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 2747 IP Network Address Translator", RFC 3027, January 2001. 2749 [20] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2750 Session Description Protocol (SDP)", RFC 3264, June 2002. 2752 [21] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2753 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2754 RFC 3711, March 2004. 2756 [22] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 2757 Address Fixing (UNSAF) Across Network Address Translation", 2758 RFC 3424, November 2002. 2760 [23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2761 Considerations Section in RFCs", BCP 26, RFC 2434, 2762 October 1998. 2764 Authors' Addresses 2766 Jonathan Rosenberg 2767 Cisco Systems 2768 600 Lanidex Plaza 2769 Parsippany, NJ 07054 2770 US 2772 Phone: +1 973 952-5000 2773 Email: jdrosen@cisco.com 2774 URI: http://www.jdrosen.net 2776 Christian Huitema 2777 Microsoft 2778 One Microsoft Way 2779 Redmond, WA 98052 2780 US 2782 Email: huitema@microsoft.com 2784 Rohan Mahy 2785 Plantronics 2786 345 Encinal Street 2787 Santa Cruz, CA 95060 2788 US 2790 Email: rohan@ekabal.com 2792 Dan Wing 2793 Cisco Systems 2794 771 Alder Drive 2795 San Jose, CA 95035 2796 US 2798 Email: dwing@cisco.com 2800 Intellectual Property Statement 2802 The IETF takes no position regarding the validity or scope of any 2803 Intellectual Property Rights or other rights that might be claimed to 2804 pertain to the implementation or use of the technology described in 2805 this document or the extent to which any license under such rights 2806 might or might not be available; nor does it represent that it has 2807 made any independent effort to identify any such rights. Information 2808 on the procedures with respect to rights in RFC documents can be 2809 found in BCP 78 and BCP 79. 2811 Copies of IPR disclosures made to the IETF Secretariat and any 2812 assurances of licenses to be made available, or the result of an 2813 attempt made to obtain a general license or permission for the use of 2814 such proprietary rights by implementers or users of this 2815 specification can be obtained from the IETF on-line IPR repository at 2816 http://www.ietf.org/ipr. 2818 The IETF invites any interested party to bring to its attention any 2819 copyrights, patents or patent applications, or other proprietary 2820 rights that may cover technology that may be required to implement 2821 this standard. Please address the information to the IETF at 2822 ietf-ipr@ietf.org. 2824 Disclaimer of Validity 2826 This document and the information contained herein are provided on an 2827 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2828 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2829 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2830 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2831 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2832 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2834 Copyright Statement 2836 Copyright (C) The Internet Society (2006). This document is subject 2837 to the rights, licenses and restrictions contained in BCP 78, and 2838 except as set forth therein, the authors retain all their rights. 2840 Acknowledgment 2842 Funding for the RFC Editor function is currently provided by the 2843 Internet Society.