idnits 2.17.1 draft-hartke-xmpp-stupid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (July 5, 2009) is 5408 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-3920bis-00 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP Working Group K. Hartke 3 Internet-Draft C. Bormann 4 Intended status: Informational Universitaet Bremen TZI 5 Expires: January 6, 2010 July 5, 2009 7 STUN/TURN using PHP in Despair 8 draft-hartke-xmpp-stupid-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 6, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 NAT (Network Address Translator) Traversal may require TURN 47 (Traversal Using Relays around NAT) functionality in certain cases 48 that are not unlikely to occur. There is little incentive to deploy 49 TURN servers, except by those who need them -- who may not be in a 50 position to deploy a new protocol on an Internet-connected node, in 51 particular not one with deployment requirements as high as those of 52 TURN. 54 "STUN/TURN using PHP in Despair" is a highly deployable protocol for 55 obtaining TURN-like functionality, while also providing the most 56 important function of STUN. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. The Need for Standardization . . . . . . . . . . . . . . . 3 62 2. Basic Protocol Operation . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Discovering External IP Address and Port . . . . . . . . . 6 66 3.3. Storing Data . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.5. Retrieving Data . . . . . . . . . . . . . . . . . . . . . 7 69 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 75 Appendix B. Sample Implementation . . . . . . . . . . . . . . . . 14 76 Appendix C. Using XMPP as Out-Of-Band Channel . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 NAT (Network Address Translator) Traversal may require TURN 82 (Traversal Using Relays around NAT) [I-D.ietf-behave-turn] 83 functionality in certain cases that are not unlikely to occur. There 84 is little incentive to deploy TURN servers, except by those who need 85 them -- who may not be in a position to deploy a new protocol on an 86 Internet-connected node, in particular not one with deployment 87 requirements as high as those of TURN. 89 "STUN/TURN using PHP in Despair" is a highly deployable protocol for 90 obtaining TURN-like functionality, while also providing the most 91 important function of STUN [RFC5389]. 93 The high degree of deployability is achieved by making STuPiD a Web 94 service, implementable in any Web application deployment scheme. As 95 PHP appears to be the solution of choice for avoiding deployment 96 problems in the Web world, a PHP-based sample implementation of 97 STuPiD is presented in Figure 5 in Appendix B. (This single-page 98 script has been tested with a free-of-charge web hoster, so it should 99 be deployable by literally everyone.) 101 1.1. The Need for Standardization 103 If STuPiD is so easy to deploy, why standardize on it? First of all, 104 STuPiD server implementations will be done by other people than the 105 clients making use of the service. Clearly communicating between 106 these communities is a good idea, in particular if there are security 107 considerations. 109 Having one standard form of STuPiD service instead of one specific to 110 each kind of client also creates an incentive for optimized 111 implementations. 113 Finally, where STuPiD becomes part of a client standard (such as a 114 potential extension to XMPP's in-band byte-stream protocol as hinted 115 in Appendix C), it is a good thing if STuPiD is already defined. 117 Hence, this document focuses on the definition of the STuPiD service 118 itself, tries to make this as general as possible without increasing 119 complexity or cost and leaves the details of any client standards to 120 future documents. 122 2. Basic Protocol Operation 124 The STuPiD protocol will typically be used with application instances 125 that first attempt to obtain connectivity using mechanisms similar to 126 those described in the STUN specification [RFC5389]. However, with 127 STuPiD, STUN is not really needed for TCP, as was demonstrated in 128 previous STUN-like implementations [STUNT]. Instead, STuPiD (like 129 [STUNT]) provides a simple Web service that echoes the remote address 130 and port of an incoming HTTP request; in most cases, this is enough 131 to get the job done. 133 In case no connection can be established with this simple STUN(T)- 134 like mechanism, a TURN-like relay is needed as a final fall-back. 135 The STuPiD protocol supports this, but solely provides a way for the 136 data to be relayed. STuPiD relies on an out-of-band channel to 137 notify the peer whenever new data is available (synchronization 138 signal). See Appendix C for one likely example of such an out-of- 139 band channel. (Note that the out-of-band channel may have a much 140 lower throughput than the STuPiD relay channel -- this is exactly the 141 case in the example provided in Appendix C, where the out-of-band 142 channel is typically throughput-limited to on the order of a few 143 kilobits per second.) 145 By designing the STuPiD web service in such a way that it can be 146 implemented by a simple PHP script such as that presented in 147 Appendix B, it is easy to deploy by those who need the STuPiD 148 services. The combination of the low-throughput out-of-band channel 149 for synchronization and the STuPiD web service for bulk data relaying 150 is somewhat silly but gets the job done. 152 The STuPiD data relay is implemented as follows (see Figure 1): 154 1. Peer A, the source of the data to be relayed, stores a chunk of 155 data at the STuPiD server using an opaque identifier, the "chunk 156 identifier". How that chunk identifier is chosen is local to 157 Peer A; it could be composed of a random session id and a 158 sequence number. 160 2. Peer A notifies the receiver of the data, Peer B, that a new data 161 chunk is available, specifying the URI needed for retrieval. 162 This notification is provided through an out-out-band channel. 163 (As an optimization for multiple consecutive transfers, A might 164 inform B once of a constant prefix of that URI and only send a 165 varying part such as a sequence number in each notification -- 166 this is something to be decided in the client-client notification 167 protocol.) 169 3. Peer B retrieves the data from the STuPiD server using the URI 170 provided by Peer A. 172 Note that the data transfer mechanism is one-way, i.e. to send data 173 in the other direction as well, Peer B needs to perform the same 174 steps using a STuPiD server at the same or a different location. 176 STuPiD ```````````````````````````````, 177 Script <----------------------------. , 178 | , 179 ^ , | , 180 | , | , 181 (1) | , | , (3) 182 POST | , | , GET 183 | , | , 184 | v | v 186 Peer A -----------------------> Peer B 187 (2) 188 out-of-band 189 Notification 191 Figure 1: STuPiD Protocol Operation 193 3. Protocol Definition 195 3.1. Terminology 197 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 198 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 199 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 200 [RFC2119] and indicate requirement levels for compliant STuPiD 201 implementations. 203 3.2. Discovering External IP Address and Port 205 A client may discover its external IP address and the port required 206 for port prediction by performing a HTTP GET request to a STuPiD 207 server. The STuPiD server MUST reply with the remote address and 208 remote port in the following format: 210 host ":" port 212 where 'host' and 'port' are defined as in [RFC3986]. 214 3.3. Storing Data 216 Data chunks are stored using the POST request of HTTP. The STuPiD 217 server MUST support one URI parameter which is passed as query- 218 string: 220 'chid': A unique ID identifying the data chunk to be stored. The ID 221 SHOULD be chosen from the characters of the base64url set [RFC4648]. 223 The payload of the POST request MUST be the data to be stored. The 224 'Content-Type' SHOULD be 'application/octet-stream', although a 225 STuPiD server implementation SHOULD simply ignore the 'Content-Type' 226 as a client implementation may be restricted and may not able to 227 specify a specific 'Content-Type'. (E.g., in certain cases, the peer 228 may be limited to sending the data as multipart-form-encoded -- 229 still, the data is stored as a byte stream.) 231 STuPiD servers may reject data chunks that are larger than some 232 predefined limit. This maximum size in bytes of each data chunk is 233 RECOMMENDED to be 65536 or more. 235 As HTTP already provides data transparency, the data chunk SHOULD NOT 236 be encoded using Base64 or any other data transparency mechanism; in 237 any case, the STuPiD server will not attempt to decode the chunk. 239 The sender MUST wait for the HTTP response before going on to notify 240 the receiver. 242 3.4. Notification 244 The sender notifies the receiver of the data chunk by passing via an 245 out-of-band channel (which is not part of the STuPiD protocol): 247 The full URL from which the data chunk can be retrieved, i.e. the 248 same URL that was used to store the data chunk, including the chunk 249 ID parameter. 251 The exact notification mechanism over the out-of-band channel and the 252 definition of a session is dependent on the out-of-band channel. See 253 Appendix C for one example of such an out-of-band channel. 255 3.5. Retrieving Data 257 The notified peer retrieves the data chunk using a GET request with 258 the URL supplied by the sender. The STuPiD server MUST set the 259 'Content-Type' of the returned body to 'application/octet-stream'. 261 4. Implementation Notes 263 A STuPiD server implementation SHOULD delete stored data some time 264 after it was stored. It is RECOMMENDED not to delete the data before 265 five minutes have elapsed after it was stored. Different client 266 protocols will have different reactions to data that have been 267 deleted prematurely and cannot be retrieved by the notified peer; 268 this may be as trivial as packet loss or it may cause a reliable 269 byte-stream to fail (Appendix B). (TODO: It may be useful to provide 270 some hints in the storing POST request.) 272 STuPiD clients should aggregate data in order to minimize the number 273 of requests to the STuPiD server per second. The specific 274 aggregation method chosen depends on the data rate required (and the 275 maximum chunk size), the latency requirements, and the application 276 semantics. 278 Clearly, it is up to the implementation to decide how the data chunks 279 are actually stored. A sufficiently silly STuPiD server 280 implementation might for instance use a MySQL database. 282 5. Security Considerations 284 The security objectives of STuPiD are to be as secure as if NAT 285 traversal had succeeded, i.e., an on-path attacker can overhear and 286 fake messages, but an off-path attacker cannot. If a higher level of 287 security is desired, it should be provided on top of the data relayed 288 by STuPiD, e.g. by using XTLS [I-D.meyer-xmpp-e2e-encryption]. 290 Much of the security of STuPiD is based on the assumption that an 291 off-path attacker cannot guess the chunk identifiers. A suitable 292 source of randomness [RFC4086] should be used to generate at least a 293 sufficiently large part of the chunk identifiers (e.g., the chunk 294 identifier could be a hard to guess prefix followed by a serial 295 number). 297 To protect the STuPiD server against denial of service and possibly 298 some forms of theft of service, it is RECOMMENDED that the POST side 299 of the STuPiD server be protected by some form of authentication such 300 as HTTP authentication. There is little need to protect the GET 301 side. 303 6. References 305 6.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 311 Resource Identifier (URI): Generic Syntax", STD 66, 312 RFC 3986, January 2005. 314 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 315 Requirements for Security", BCP 106, RFC 4086, June 2005. 317 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 318 Encodings", RFC 4648, October 2006. 320 6.2. Informative References 322 [I-D.ietf-behave-turn] 323 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 324 Relays around NAT (TURN): Relay Extensions to Session 325 Traversal Utilities for NAT (STUN)", 326 draft-ietf-behave-turn-16 (work in progress), July 2009. 328 [I-D.ietf-xmpp-3920bis] 329 Saint-Andre, P., "Extensible Messaging and Presence 330 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-00 (work 331 in progress), June 2009. 333 [I-D.meyer-xmpp-e2e-encryption] 334 Meyer, D. and P. Saint-Andre, "XTLS: End-to-End Encryption 335 for the Extensible Messaging and Presence Protocol (XMPP) 336 Using Transport Layer Security (TLS)", 337 draft-meyer-xmpp-e2e-encryption-02 (work in progress), 338 June 2009. 340 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 341 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 342 October 2008. 344 [STUNT] Hanson, R., "STUNT & out-of-band channels", 345 September 2007, . 348 Appendix A. Examples 350 This appendix provides some examples of the STuPiD protocol 351 operation. 353 Request: 355 GET /stupid.php HTTP/1.0 356 User-Agent: Example/1.11.4 357 Accept: */* 358 Host: example.org 359 Connection: Keep-Alive 361 Response: 363 HTTP/1.1 200 OK 364 Date: Sun, 05 Jul 2009 00:30:37 GMT 365 Server: Apache/2.2 366 Cache-Control: no-cache, must-revalidate 367 Expires: Sat, 26 Jul 1997 05:00:00 GMT 368 Vary: Accept-Encoding 369 Content-Length: 17 370 Keep-Alive: timeout=1, max=400 371 Connection: Keep-Alive 372 Content-Type: application/octet-stream 374 192.0.2.239:36654 376 Figure 2: Discovering External IP Address and Port 378 Request: 380 POST /stupid.php?chid=i781hf64-0 HTTP/1.0 381 User-Agent: Example/1.11.4 382 Accept: */* 383 Host: example.org 384 Connection: Keep-Alive 385 Content-Type: application/octet-stream 386 Content-Length: 11 388 Hello World 390 Response: 392 HTTP/1.1 200 OK 393 Date: Sun, 05 Jul 2009 00:20:34 GMT 394 Server: Apache/2.2 395 Cache-Control: no-cache, must-revalidate 396 Expires: Sat, 26 Jul 1997 05:00:00 GMT 397 Vary: Accept-Encoding 398 Content-Length: 0 399 Keep-Alive: timeout=1, max=400 400 Connection: Keep-Alive 401 Content-Type: application/octet-stream 403 Figure 3: Storing Data 405 Request: 407 GET /stupid.php?chid=i781hf64-0 HTTP/1.0 408 User-Agent: Example/1.11.4 409 Accept: */* 410 Host: example.org 411 Connection: Keep-Alive 413 Response: 415 HTTP/1.1 200 OK 416 Date: Sun, 05 Jul 2009 00:21:29 GMT 417 Server: Apache/2.2 418 Cache-Control: no-cache, must-revalidate 419 Expires: Sat, 26 Jul 1997 05:00:00 GMT 420 Vary: Accept-Encoding 421 Content-Length: 11 422 Keep-Alive: timeout=1, max=400 423 Connection: Keep-Alive 424 Content-Type: application/octet-stream 426 Hello World 428 Figure 4: Retrieving Data 430 Appendix B. Sample Implementation 432 475 Figure 5: STuPiD Sample Implementation 477 Appendix C. Using XMPP as Out-Of-Band Channel 479 XMPP [I-D.ietf-xmpp-3920bis] is a good choice for an out-of-band 480 channel. 482 The notification protocol is closely modeled after XMPP's In-Band 483 Bytestreams (IBB, see http://xmpp.org/extensions/xep-0047.html). 484 Just replace the namespace and insert the STuPiD Retrieval URI 485 instead of the actual Base64 encoded data, see Figure 8. (Note that 486 the current proposal redundantly sends a sid and a seq as well as the 487 chid composed of these two; it may be possible to optimize this, 488 possibly sending the constant prefix of the URI once at bytestream 489 creation time.) 491 Notifications MUST be processed in the order they are received. If 492 an out-of-sequence notification is received for a particular session 493 (determined by checking the 'seq' attribute), then this indicates 494 that a notification has been lost. The recipient MUST NOT process 495 such an out-of-sequence notification, nor any that follow it within 496 the same session; instead, the recipient MUST consider the session 497 invalid. (Adapted from 498 http://xmpp.org/extensions/xep-0047.html#send) 500 Of course, other methods can be used for setup and teardown, such as 501 Jingle (see http://xmpp.org/extensions/xep-0261.html). 503 507 511 513 Figure 6: Creating a Bytestream: Initiator requests session 515 520 Figure 7: Creating a Bytestream: Responder accepts session 521 525 529 531 Figure 8: Sending Notifications: Notification in an IQ stanza 533 538 Figure 9: Sending Notifications: Acknowledging notification using IQ 540 544 546 548 Figure 10: Closing the Bytestream: Request 550 555 Figure 11: Closing the Bytestream: Success response 557 Authors' Addresses 559 Klaus Hartke 560 Universitaet Bremen TZI 562 Email: hartke@tzi.org 564 Carsten Bormann 565 Universitaet Bremen TZI 566 Postfach 330440 567 Bremen D-28359 568 Germany 570 Phone: +49-421-218-63921 571 Fax: +49-421-218-7000 572 Email: cabo@tzi.org