idnits 2.17.1 draft-alvestrand-dispatch-rtcweb-datagram-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 15, 2011) is 4819 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5766' is defined on line 318, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-hybi-thewebsocketprotocol-00 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-08 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Experimental February 15, 2011 5 Expires: August 19, 2011 7 A Datagram Transport for the RTC-Web profile 8 draft-alvestrand-dispatch-rtcweb-datagram-01 10 Abstract 12 This document describes a combination and profiling of existing IETF 13 protocols to provide a datagram service that is suitable as a generic 14 transport substrate for the RTC-Web family of real-time audio/video 15 applications. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 19, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Service model . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Channel types . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. UDP channel . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. TCP channel . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.3. TLS channel . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.4. DTLS channel . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.5. WebSockets channel . . . . . . . . . . . . . . . . . . . . 5 66 4.6. Channels with relay . . . . . . . . . . . . . . . . . . . . 5 67 5. Channel setup, teardown and usage . . . . . . . . . . . . . . . 5 68 6. An URI scheme for datagram channels . . . . . . . . . . . . . . 6 69 6.1. new section . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 76 Appendix A. Change history . . . . . . . . . . . . . . . . . . . . 8 77 A.1. Changes from alvestrand-00 to alvestrand-01 . . . . . . . . 8 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 When transporting audio / video and other realtime data between 83 participants on the current Internet, there are a number of obstacles 84 to be faced. 86 Among them are NAT boxes, firewalls, connection interruptions, the 87 availability of multiple paths between participants, and capacity 88 issues. 90 This memo describes a combination of existing protocols that can be 91 used to achieve a seamless datagram transport service across this 92 very heterogenous environment. 94 An overview of the effort of which this is a part can be found in the 95 overview document, [overview]. 97 2. Terminology 99 This draft uses a couple of commonly used terms in quite specific 100 ways. The reader is advised to study these definitions carefully. 102 (TODO: Agree on terminology to use) 104 Session An association with two endpoints, between which datagrams 105 flow. 107 Datagram A sequence of octets, of a given length. In this 108 specification, a datagram does not carry addressing information. 110 Channel One means of transporting a datagram over a session. A 111 session may have multiple channels at any time. 115 Endpoint One end of a session. This document does not distinguish 116 between an initiator and a responder endpoint. 118 Control channel A means of communication between the endpoints of a 119 session that does not require a transport to be active. 120 Typically, authentication, authorization and negotiation is 121 carried out over the control channel. The specification of the 122 control channel is out of scope for this specification. 124 3. Service model 126 The basic model presented is a datagram model. On top of this one 127 can layer various services, such as pseudoTCP (REF), RTP[RFC3550] or 128 any other higher layer protocol that is capable of running across a 129 datagram service. (If a TCP connection can be established between 130 the parties, this is usually the preferred option for reliable, 131 sequenced transfer. The use of this datagram service for reliable 132 transfer should be considered an option available for the case where 133 only UDP connectivity is available.) 135 The addressing model departs from the traditional Internet model in 136 that end point addresses are not used for endpoint identification, 137 only for channel establisment; instead, an initial packet exchange, 138 using ICE [RFC5245], is used to bind a channel to a prenegotiated 139 session. 141 The datagram service is not completely transparent; in particular, it 142 is not possible to carry a datagram where the two highest bits of the 143 first octet are zero and octet 5 to 8 contain the value 0x2112A442, 144 since these datagrams are reserved for use of the STUN protocol (RFC 145 5389 section 6). 147 4. Channel types 149 4.1. UDP channel 151 An UDP channel is negotiated using ICE. Each datagram is simply 152 carried as the content of an UDP packet. 154 4.2. TCP channel 156 A TCP channel consists of a TCP connection, over which are sent 157 datagrams packaged according to RFC 4571 [RFC4571]. The binding of a 158 TCP channel is done by executing an ICE negotiation over the first 159 few packets passed across the TCP channel, as specified in ICE-TCP 160 [I-D.ietf-mmusic-ice-tcp] 162 4.3. TLS channel 164 A TLS channel consists of a standard TLS negotiation, followed by 165 passing datagrams over the TLS record layer[RFC5246] section 6.2. 166 There is no extra length field. A TLS channel is bound to its 167 session by . 169 4.4. DTLS channel 171 A DTLS channel is created by executing a DTLS [RFC5238] connection 172 negotiation, followed by datagram exchange, where the datagrams are 173 protected by DTLS mechanisms. The DTLS channel is bound to its 174 session by . 176 4.5. WebSockets channel 178 A WebSockets channel uses the WebSockets 179 protocol[I-D.ietf-hybi-thewebsocketprotocol] to pass datagrams as 180 binary packets. 182 4.6. Channels with relay 184 If there is no possibility of setting up a direct connection, a relay 185 must be used. When both parties are reachable using UDP candidates, 186 the specification from TURN [RFC5766]is used. 190 5. Channel setup, teardown and usage 192 The service model envisioned here is that all datagrams arriving on a 193 session are considered equally valid. The session gives no 194 guarantees against duplication, loss or reordering; such concerns are 195 left to the higher protocol layers. 197 The expected normal usage is that two endpoints will exchange 198 addressing information that can be used for a series of potential 199 channels, that the endpoints will probe for working channels using 200 ICE (RFC 5245), and use the "best" candidate, while using the STUN 201 probing facilities to keep some number of "second best" candidates 202 alive if the "best" candidate stops working. 204 A data-sending endpoint may unilaterally decide to start or stop 205 using an established channel at any time. No negotiation is 206 necessary. 208 A receiving endpoint will learn that a channel has been removed by 209 not seeing any more STUN keepalive messages on that channel within 210 . 212 A session is considered closed when all channels that have been 213 successfully established have timed out. 215 6. An URI scheme for datagram channels 217 This URI scheme is mainly included in order to make it easy for APIs 218 that normally use URIs as what they use to refer to objects. It 219 reflects exactly the information found in the SDP attributes defined 220 in RFC 5245 section 15. 222 226 The DGSESSION URI scheme specifies the information required for a 227 session; it consists of two parts: 229 o An absolute reference, which includes the user name and password 230 used to establish channels over this connection. 232 o A series of addressing hints, which include the data necessary to 233 establish a channel. 235 237 Example: 239 dgsession:username:password?ipv4:12.34.56:udp:12345& 240 ipv6:2002::dead:beef:tcp:80&ipv4:12.34.56.78:tls:443 242 The sequence of addressing hints is an indication of the preference 243 of the URL constructor for the sequence in which to try these 244 candidates; the most preferred address is the one to the left. 246 Note that a DGSESSION URI is a capability; anyone with the URI will 247 be able to connect to the entity. They should therefore be handled 248 in the same way as (short-term) passwords, and never passed in the 249 clear. 251 6.1. new section 253 7. IANA Considerations 255 This document registers the URI scheme from section Paragraph 1. 257 Note to RFC Editor: this section may be removed on publication as an 258 RFC. 260 8. Security Considerations 262 As with all layered protocols, it is a matter for the application to 263 decide which level security should be provided at. For instance, an 264 RTP session protected using SRTP can be considered to not need 265 any further safeguards against interception, modification or replay, 266 so can be passed "in the clear" across any channel type here. For 267 data without such protection, adequate measures need to be taken; in 268 particular, it is trivially easy for someone with the ability to 269 snoop and insert packets to insert fake packets into an established 270 UDP channel. 272 The main defense against denial-of-service attacks is the fact that 273 the ICE mechanisms were designed for low cost refusal of unauthorized 274 connections. 276 9. Acknowledgements 278 Thanks to Markus Isomaki for reviewing version -00. 280 10. References 282 10.1. Normative References 284 [I-D.ietf-hybi-thewebsocketprotocol] 285 Hickson, I., "The WebSocket protocol", 286 draft-ietf-hybi-thewebsocketprotocol-00 (work in 287 progress), May 2010. 289 [I-D.ietf-mmusic-ice-tcp] 290 Perreault, S. and J. Rosenberg, "TCP Candidates with 291 Interactive Connectivity Establishment (ICE)", 292 draft-ietf-mmusic-ice-tcp-08 (work in progress), 293 October 2009. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 299 Jacobson, "RTP: A Transport Protocol for Real-Time 300 Applications", STD 64, RFC 3550, July 2003. 302 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 303 and RTP Control Protocol (RTCP) Packets over Connection- 304 Oriented Transport", RFC 4571, July 2006. 306 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 307 the Datagram Congestion Control Protocol (DCCP)", 308 RFC 5238, May 2008. 310 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 311 (ICE): A Protocol for Network Address Translator (NAT) 312 Traversal for Offer/Answer Protocols", RFC 5245, 313 April 2010. 315 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 316 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 318 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 319 Relays around NAT (TURN): Relay Extensions to Session 320 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 322 10.2. Informative References 324 [overview] 325 Alvestrand, H., "Overview: Real Time Protocols for Brower- 326 based Applications", November 2010. 328 Appendix A. Change history 330 A.1. Changes from alvestrand-00 to alvestrand-01 332 Added the WebSockets channel option. Made some changes and 333 clarifications, mainly based on Markus Isomaki's review. Pointed out 334 that the DGSESSION URI scheme has to represent exactly the semantics 335 of the SDP extensions for ICE. 337 Author's Address 339 Harald Tveit Alvestrand 340 Google 341 Kungsbron 2 342 Stockholm, 11122 343 Sweden 345 Email: harald@alvestrand.no