XMPP Working Group K. Hartke
Internet-Draft C. Bormann
Intended status: Informational Universitaet Bremen TZI
Expires: January 6, 2010 July 5, 2009
STUN/TURN using PHP in Despair
draft-hartke-xmpp-stupid-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Hartke & Bormann Expires January 6, 2010 [Page 1]
Internet-Draft STuPiD July 2009
Abstract
NAT (Network Address Translator) Traversal may require TURN
(Traversal Using Relays around NAT) functionality in certain cases
that are not unlikely to occur. There is little incentive to deploy
TURN servers, except by those who need them -- who may not be in a
position to deploy a new protocol on an Internet-connected node, in
particular not one with deployment requirements as high as those of
TURN.
"STUN/TURN using PHP in Despair" is a highly deployable protocol for
obtaining TURN-like functionality, while also providing the most
important function of STUN.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Need for Standardization . . . . . . . . . . . . . . . 3
2. Basic Protocol Operation . . . . . . . . . . . . . . . . . . . 4
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 6
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Discovering External IP Address and Port . . . . . . . . . 6
3.3. Storing Data . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Retrieving Data . . . . . . . . . . . . . . . . . . . . . 7
4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Sample Implementation . . . . . . . . . . . . . . . . 14
Appendix C. Using XMPP as Out-Of-Band Channel . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Hartke & Bormann Expires January 6, 2010 [Page 2]
Internet-Draft STuPiD July 2009
1. Introduction
NAT (Network Address Translator) Traversal may require TURN
(Traversal Using Relays around NAT) [I-D.ietf-behave-turn]
functionality in certain cases that are not unlikely to occur. There
is little incentive to deploy TURN servers, except by those who need
them -- who may not be in a position to deploy a new protocol on an
Internet-connected node, in particular not one with deployment
requirements as high as those of TURN.
"STUN/TURN using PHP in Despair" is a highly deployable protocol for
obtaining TURN-like functionality, while also providing the most
important function of STUN [RFC5389].
The high degree of deployability is achieved by making STuPiD a Web
service, implementable in any Web application deployment scheme. As
PHP appears to be the solution of choice for avoiding deployment
problems in the Web world, a PHP-based sample implementation of
STuPiD is presented in Figure 5 in Appendix B. (This single-page
script has been tested with a free-of-charge web hoster, so it should
be deployable by literally everyone.)
1.1. The Need for Standardization
If STuPiD is so easy to deploy, why standardize on it? First of all,
STuPiD server implementations will be done by other people than the
clients making use of the service. Clearly communicating between
these communities is a good idea, in particular if there are security
considerations.
Having one standard form of STuPiD service instead of one specific to
each kind of client also creates an incentive for optimized
implementations.
Finally, where STuPiD becomes part of a client standard (such as a
potential extension to XMPP's in-band byte-stream protocol as hinted
in Appendix C), it is a good thing if STuPiD is already defined.
Hence, this document focuses on the definition of the STuPiD service
itself, tries to make this as general as possible without increasing
complexity or cost and leaves the details of any client standards to
future documents.
Hartke & Bormann Expires January 6, 2010 [Page 3]
Internet-Draft STuPiD July 2009
2. Basic Protocol Operation
The STuPiD protocol will typically be used with application instances
that first attempt to obtain connectivity using mechanisms similar to
those described in the STUN specification [RFC5389]. However, with
STuPiD, STUN is not really needed for TCP, as was demonstrated in
previous STUN-like implementations [STUNT]. Instead, STuPiD (like
[STUNT]) provides a simple Web service that echoes the remote address
and port of an incoming HTTP request; in most cases, this is enough
to get the job done.
In case no connection can be established with this simple STUN(T)-
like mechanism, a TURN-like relay is needed as a final fall-back.
The STuPiD protocol supports this, but solely provides a way for the
data to be relayed. STuPiD relies on an out-of-band channel to
notify the peer whenever new data is available (synchronization
signal). See Appendix C for one likely example of such an out-of-
band channel. (Note that the out-of-band channel may have a much
lower throughput than the STuPiD relay channel -- this is exactly the
case in the example provided in Appendix C, where the out-of-band
channel is typically throughput-limited to on the order of a few
kilobits per second.)
By designing the STuPiD web service in such a way that it can be
implemented by a simple PHP script such as that presented in
Appendix B, it is easy to deploy by those who need the STuPiD
services. The combination of the low-throughput out-of-band channel
for synchronization and the STuPiD web service for bulk data relaying
is somewhat silly but gets the job done.
The STuPiD data relay is implemented as follows (see Figure 1):
1. Peer A, the source of the data to be relayed, stores a chunk of
data at the STuPiD server using an opaque identifier, the "chunk
identifier". How that chunk identifier is chosen is local to
Peer A; it could be composed of a random session id and a
sequence number.
2. Peer A notifies the receiver of the data, Peer B, that a new data
chunk is available, specifying the URI needed for retrieval.
This notification is provided through an out-out-band channel.
(As an optimization for multiple consecutive transfers, A might
inform B once of a constant prefix of that URI and only send a
varying part such as a sequence number in each notification --
this is something to be decided in the client-client notification
protocol.)
Hartke & Bormann Expires January 6, 2010 [Page 4]
Internet-Draft STuPiD July 2009
3. Peer B retrieves the data from the STuPiD server using the URI
provided by Peer A.
Note that the data transfer mechanism is one-way, i.e. to send data
in the other direction as well, Peer B needs to perform the same
steps using a STuPiD server at the same or a different location.
STuPiD ```````````````````````````````,
Script Peer B
(2)
out-of-band
Notification
Figure 1: STuPiD Protocol Operation
Hartke & Bormann Expires January 6, 2010 [Page 5]
Internet-Draft STuPiD July 2009
3. Protocol Definition
3.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STuPiD
implementations.
3.2. Discovering External IP Address and Port
A client may discover its external IP address and the port required
for port prediction by performing a HTTP GET request to a STuPiD
server. The STuPiD server MUST reply with the remote address and
remote port in the following format:
host ":" port
where 'host' and 'port' are defined as in [RFC3986].
3.3. Storing Data
Data chunks are stored using the POST request of HTTP. The STuPiD
server MUST support one URI parameter which is passed as query-
string:
'chid': A unique ID identifying the data chunk to be stored. The ID
SHOULD be chosen from the characters of the base64url set [RFC4648].
The payload of the POST request MUST be the data to be stored. The
'Content-Type' SHOULD be 'application/octet-stream', although a
STuPiD server implementation SHOULD simply ignore the 'Content-Type'
as a client implementation may be restricted and may not able to
specify a specific 'Content-Type'. (E.g., in certain cases, the peer
may be limited to sending the data as multipart-form-encoded --
still, the data is stored as a byte stream.)
STuPiD servers may reject data chunks that are larger than some
predefined limit. This maximum size in bytes of each data chunk is
RECOMMENDED to be 65536 or more.
As HTTP already provides data transparency, the data chunk SHOULD NOT
be encoded using Base64 or any other data transparency mechanism; in
any case, the STuPiD server will not attempt to decode the chunk.
The sender MUST wait for the HTTP response before going on to notify
the receiver.
Hartke & Bormann Expires January 6, 2010 [Page 6]
Internet-Draft STuPiD July 2009
3.4. Notification
The sender notifies the receiver of the data chunk by passing via an
out-of-band channel (which is not part of the STuPiD protocol):
The full URL from which the data chunk can be retrieved, i.e. the
same URL that was used to store the data chunk, including the chunk
ID parameter.
The exact notification mechanism over the out-of-band channel and the
definition of a session is dependent on the out-of-band channel. See
Appendix C for one example of such an out-of-band channel.
3.5. Retrieving Data
The notified peer retrieves the data chunk using a GET request with
the URL supplied by the sender. The STuPiD server MUST set the
'Content-Type' of the returned body to 'application/octet-stream'.
Hartke & Bormann Expires January 6, 2010 [Page 7]
Internet-Draft STuPiD July 2009
4. Implementation Notes
A STuPiD server implementation SHOULD delete stored data some time
after it was stored. It is RECOMMENDED not to delete the data before
five minutes have elapsed after it was stored. Different client
protocols will have different reactions to data that have been
deleted prematurely and cannot be retrieved by the notified peer;
this may be as trivial as packet loss or it may cause a reliable
byte-stream to fail (Appendix B). (TODO: It may be useful to provide
some hints in the storing POST request.)
STuPiD clients should aggregate data in order to minimize the number
of requests to the STuPiD server per second. The specific
aggregation method chosen depends on the data rate required (and the
maximum chunk size), the latency requirements, and the application
semantics.
Clearly, it is up to the implementation to decide how the data chunks
are actually stored. A sufficiently silly STuPiD server
implementation might for instance use a MySQL database.
Hartke & Bormann Expires January 6, 2010 [Page 8]
Internet-Draft STuPiD July 2009
5. Security Considerations
The security objectives of STuPiD are to be as secure as if NAT
traversal had succeeded, i.e., an on-path attacker can overhear and
fake messages, but an off-path attacker cannot. If a higher level of
security is desired, it should be provided on top of the data relayed
by STuPiD, e.g. by using XTLS [I-D.meyer-xmpp-e2e-encryption].
Much of the security of STuPiD is based on the assumption that an
off-path attacker cannot guess the chunk identifiers. A suitable
source of randomness [RFC4086] should be used to generate at least a
sufficiently large part of the chunk identifiers (e.g., the chunk
identifier could be a hard to guess prefix followed by a serial
number).
To protect the STuPiD server against denial of service and possibly
some forms of theft of service, it is RECOMMENDED that the POST side
of the STuPiD server be protected by some form of authentication such
as HTTP authentication. There is little need to protect the GET
side.
Hartke & Bormann Expires January 6, 2010 [Page 9]
Internet-Draft STuPiD July 2009
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
6.2. Informative References
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-16 (work in progress), July 2009.
[I-D.ietf-xmpp-3920bis]
Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-00 (work
in progress), June 2009.
[I-D.meyer-xmpp-e2e-encryption]
Meyer, D. and P. Saint-Andre, "XTLS: End-to-End Encryption
for the Extensible Messaging and Presence Protocol (XMPP)
Using Transport Layer Security (TLS)",
draft-meyer-xmpp-e2e-encryption-02 (work in progress),
June 2009.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[STUNT] Hanson, R., "STUNT & out-of-band channels",
September 2007, .
Hartke & Bormann Expires January 6, 2010 [Page 10]
Internet-Draft STuPiD July 2009
Appendix A. Examples
This appendix provides some examples of the STuPiD protocol
operation.
Request:
GET /stupid.php HTTP/1.0
User-Agent: Example/1.11.4
Accept: */*
Host: example.org
Connection: Keep-Alive
Response:
HTTP/1.1 200 OK
Date: Sun, 05 Jul 2009 00:30:37 GMT
Server: Apache/2.2
Cache-Control: no-cache, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Vary: Accept-Encoding
Content-Length: 17
Keep-Alive: timeout=1, max=400
Connection: Keep-Alive
Content-Type: application/octet-stream
192.0.2.239:36654
Figure 2: Discovering External IP Address and Port
Hartke & Bormann Expires January 6, 2010 [Page 11]
Internet-Draft STuPiD July 2009
Request:
POST /stupid.php?chid=i781hf64-0 HTTP/1.0
User-Agent: Example/1.11.4
Accept: */*
Host: example.org
Connection: Keep-Alive
Content-Type: application/octet-stream
Content-Length: 11
Hello World
Response:
HTTP/1.1 200 OK
Date: Sun, 05 Jul 2009 00:20:34 GMT
Server: Apache/2.2
Cache-Control: no-cache, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Vary: Accept-Encoding
Content-Length: 0
Keep-Alive: timeout=1, max=400
Connection: Keep-Alive
Content-Type: application/octet-stream
Figure 3: Storing Data
Hartke & Bormann Expires January 6, 2010 [Page 12]
Internet-Draft STuPiD July 2009
Request:
GET /stupid.php?chid=i781hf64-0 HTTP/1.0
User-Agent: Example/1.11.4
Accept: */*
Host: example.org
Connection: Keep-Alive
Response:
HTTP/1.1 200 OK
Date: Sun, 05 Jul 2009 00:21:29 GMT
Server: Apache/2.2
Cache-Control: no-cache, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Vary: Accept-Encoding
Content-Length: 11
Keep-Alive: timeout=1, max=400
Connection: Keep-Alive
Content-Type: application/octet-stream
Hello World
Figure 4: Retrieving Data
Hartke & Bormann Expires January 6, 2010 [Page 13]
Internet-Draft STuPiD July 2009
Appendix B. Sample Implementation
Figure 5: STuPiD Sample Implementation
Hartke & Bormann Expires January 6, 2010 [Page 14]
Internet-Draft STuPiD July 2009
Appendix C. Using XMPP as Out-Of-Band Channel
XMPP [I-D.ietf-xmpp-3920bis] is a good choice for an out-of-band
channel.
The notification protocol is closely modeled after XMPP's In-Band
Bytestreams (IBB, see http://xmpp.org/extensions/xep-0047.html).
Just replace the namespace and insert the STuPiD Retrieval URI
instead of the actual Base64 encoded data, see Figure 8. (Note that
the current proposal redundantly sends a sid and a seq as well as the
chid composed of these two; it may be possible to optimize this,
possibly sending the constant prefix of the URI once at bytestream
creation time.)
Notifications MUST be processed in the order they are received. If
an out-of-sequence notification is received for a particular session
(determined by checking the 'seq' attribute), then this indicates
that a notification has been lost. The recipient MUST NOT process
such an out-of-sequence notification, nor any that follow it within
the same session; instead, the recipient MUST consider the session
invalid. (Adapted from
http://xmpp.org/extensions/xep-0047.html#send)
Of course, other methods can be used for setup and teardown, such as
Jingle (see http://xmpp.org/extensions/xep-0261.html).
Figure 6: Creating a Bytestream: Initiator requests session
Figure 7: Creating a Bytestream: Responder accepts session
Hartke & Bormann Expires January 6, 2010 [Page 15]
Internet-Draft STuPiD July 2009
Figure 8: Sending Notifications: Notification in an IQ stanza
Figure 9: Sending Notifications: Acknowledging notification using IQ
Figure 10: Closing the Bytestream: Request
Figure 11: Closing the Bytestream: Success response
Hartke & Bormann Expires January 6, 2010 [Page 16]
Internet-Draft STuPiD July 2009
Authors' Addresses
Klaus Hartke
Universitaet Bremen TZI
Email: hartke@tzi.org
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Fax: +49-421-218-7000
Email: cabo@tzi.org
Hartke & Bormann Expires January 6, 2010 [Page 17]