RTCWEB M. Kaufman Internet-Draft Skype Intended status: Standards Track June 30, 2011 Expires: January 1, 2012 draft-kaufman-rtp-compatible-data-00 Abstract This document describes a method for sending unreliable datagrams that are "compatible" with RTP and RTCP, and STUN usage of a shared UDP address and port. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 1, 2012. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kaufman Expires January 1, 2012 [Page 1] Internet-Draft June 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3 4. Alternatives Considered . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Kaufman Expires January 1, 2012 [Page 2] Internet-Draft June 2011 1. Introduction There is a desire to support the transmssion of unreliable datagrams to a UDP receiver that is also receiving RTP and RTCP [RFC3550] (and STUN [RFC5389]) datagrams at the same address and port. One possible application is to add this ability to RTCWEB clients for direct peer- to-peer transmission of arbitrary data between clients. The desire to share the same UDP port is driven, in part, by the reduction in the number of NAT bindings that would be required to simultaneously support media and data transmission. It is also driven by the desire to reuse STUN [RFC5389] connectivity checks and ICE [RFC5245] as the mechanism whereby receiver consent is obtained (confirmation that the receiver is willing to receive data from this sender) and as the mechanism for NAT traversal. 2. Constraints The format of these datagrams have several constraints: RTP: These datagrams must not be decoded as RTP datagrams. RTCP: These datagrams must not be decoded as RTCP datagrams. Future Versions: These datagrams must not prevent the future deployment of new versions of RTP or RTCP. STUN: These datagrams must not be decoded as valid STUN messages. 3. Protocol Description All such messages MUST start with a 4-byte header as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | User Message Data | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Kaufman Expires January 1, 2012 [Page 3] Internet-Draft June 2011 The most significant 2 bits of every such message MUST be zero. This can be used to differentiate these messages from all protocols other than STUN that are multiplexed on the same port (e.g., RTP, RTCP). The next 14 bits of every such message MUST be zero. If interpreted by a STUN implementation, this will encode a message type of 0x000, which is reserved, and class (if using RFC5389) of 0b00 (Request). The reserved message type is not an allowed STUN message, thus differentiating such messages from STUN messages. In order to further prevent STUN implementations from interpreting these datagrams the next 16 bits of every such message MUST be zero. This results in a field of all zeros at the position of the STUN length field. This ensures that even if the arbitrary data that follows were to simulate the STUN cookie (which is unlikely) the STUN receiver would find no attributes. The choice of setting the high two bits to zero does require that the receiver that wishes to receive these datagrams must intercept them prior to them being received and then discarded by the STUN implementation, if present. 4. Alternatives Considered One alternative considered was to encapsulate the arbitrary datagrams within RTP as an RTP payload type. However the semantics associated with RTP are not always appropriate, depending on the type of arbitrary data being transmitted. 5. Security Considerations The contents of these messages SHOULD be encrypted. Reuse of the keying used for an associated RTP session that is using the same IP address and port MAY be an acceptable method of key specification and cryptosystem choice. These messages MUST only be sent by RTCWEB clients that have already verified that the recipient is willing to receive data via a mechanism such as ICE. If consent is received and because these messages have an inflexible (that is to say, not settable by an untrusted client such as a browser) header of 4 zero bytes, it is unlikely that these messages could be used to spoof other types of protocols, even if software running within an untrusted client (i.e., web browser) is able to specify the entire content of the message after the header. If this Kaufman Expires January 1, 2012 [Page 4] Internet-Draft June 2011 guarantee is not strong enough, an additional header with a magic cookie similar to (but different in value from) the STUN cookie could be added. Because these messages are transmitted as UDP datagrams, it is unlikely that proxy devices will misinterpret the contents of the messages, and thus masking techniques (such as those discussed for WebSockets) are probably not necessary even over unencrypted channels. 6. Informative References [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Author's Address Matthew Kaufman Skype 3210 Porter Drive Palo Alto, California 95060 US Phone: +1 831 440 8771 Email: matthew.kaufman@skype.net Kaufman Expires January 1, 2012 [Page 5]