idnits 2.17.1 draft-ietf-rtcweb-transports-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 date (September 3, 2013) is 3887 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) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-04 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-05 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-07 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-05 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-01 == Outdated reference: A later version (-08) exists of draft-nandakumar-rtcweb-stun-uri-05 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-03) exists of draft-hutton-rtcweb-nat-firewall-considerations-01 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-07 Summary: 2 errors (**), 0 flaws (~~), 10 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: Standards Track September 3, 2013 5 Expires: March 7, 2014 7 Transports for RTCWEB 8 draft-ietf-rtcweb-transports-01 10 Abstract 12 This document describes the data transport protocols used by RTCWEB, 13 including the protocols used for interaction with intermediate boxes 14 such as firewalls, relays and NAT boxes. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 7, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Transport and Middlebox specification . . . . . . . . . . . . . 3 58 2.1. System-provided interfaces . . . . . . . . . . . . . . . . 3 59 2.2. Middle box related functions . . . . . . . . . . . . . . . 4 60 2.3. Transport protocols implemented . . . . . . . . . . . . . . 4 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . . 7 68 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 The IETF RTCWEB effort, part of the WebRTC effort carried out in 74 cooperation between the IETF and the W3C, is aimed at specifying a 75 protocol suite that is useful for real time multimedia exchange 76 between browsers. 78 The overall effort is described in the RTCWEB overview document, 79 [I-D.ietf-rtcweb-overview]. This document focuses on the data 80 transport protocos that are used by conforming implementations. 82 This protocol suite is designed for WebRTC, and intends to satisfy 83 the security considerations described in the WebRTC security 84 documents, [I-D.ietf-rtcweb-security] and 85 [I-D.ietf-rtcweb-security-arch]. 87 2. Transport and Middlebox specification 89 2.1. System-provided interfaces 91 The protocol specifications used here assume that the following 92 protocols are available to the implementations of the RTCWEB 93 protocols: 95 o UDP. This is the protocol assumed by most protocol elements 96 described. 98 o TCP. This is used for HTTP/WebSockets, as well as for TURN/SSL 99 and ICE-TCP. 101 For both protocols, this specification assumes the ability to set the 102 DSCP code point of the sockets opened on a per-packet basis, in order 103 to achieve the prioritizations described in [I-D.ietf-rtcweb-qos]. 104 It does not assume that the DSCP codepoints will be honored, and does 105 assume that they may be zeroed or changed, since this is a local 106 configuration issue. 108 If DSCP code points can only be set on a per-socket basis, not per- 109 packet, one loses the ability to have the network discriminate 110 reliably between classes of traffic sent over the same transport, but 111 this does not prevent communication. 113 This specification does not assume that the implementation will have 114 access to ICMP or raw IP. 116 2.2. Middle box related functions 118 The primary mechanism to deal with middle boxes is ICE, which is an 119 appropriate way to deal with NAT boxes and firewalls that accept 120 traffic from the inside, but only from the outside if it's in 121 response to inside traffic (simple stateful firewalls). 123 In order to deal with situations where both parties are behind NATs 124 which perform endpoint-dependent mapping (as defined in [RFC5128] 125 section 2.4), TURN [RFC5766] MUST be supported. 127 In order to deal with firewalls that block all UDP traffic, TURN 128 using TCP between the client and the server MUST be supported, and 129 TURN using TLS between the client and the server MUST be supported. 131 ICE TCP candidates [RFC6062] MAY be supported; this may allow 132 applications to achieve peer-to-peer communication across UDP- 133 blocking firewalls, but this also requires use of the SRTP/AVPF/TCP 134 profile of RTP. 136 The following specifications MUST be supported: 138 o ICE [RFC5245] 140 o TURN, including TURN over TCP[RFC5766]. 142 TURN over TLS over TCP MAY be supported. (QUESTION: SHOULD? MUST?) 144 For referring to STUN and TURN servers, this specification depends on 145 the STUN URI, [I-D.nandakumar-rtcweb-stun-uri]. 147 Further discussion of the interaction of RTCWEB with firewalls is 148 contained in [I-D.hutton-rtcweb-nat-firewall-considerations]. This 149 document makes no requirements on interacting with HTTP proxies or 150 HTTP proxy configuration methods. 152 2.3. Transport protocols implemented 154 For data transport over the RTCWEB data channel 155 [I-D.ietf-rtcweb-data-channel], RTCWEB implementations support SCTP 156 over DTLS over ICE. This is specified in 157 [I-D.ietf-tsvwg-sctp-dtls-encaps]. Negotiation of this transport in 158 SCTP is defined in [I-D.ietf-mmusic-sctp-sdp]. 160 The setup protocol for RTCWEB data channels is described in 161 [I-D.jesup-rtcweb-data-protocol]. 163 For transport of media, secure RTP is used. The details of the 164 profile of RTP used are described in "RTP Usage" 165 [I-D.ietf-rtcweb-rtp-usage]. 167 RTCWEB implementations MUST support multiplexing of DTLS and RTP over 168 the same port pair, as described in the DTLS_SRTP specification 169 [RFC5764], section 5.1.2. Further separation of the DTLS traffic 170 into SCTP and "other" is described in . 172 3. IANA Considerations 174 This document makes no request of IANA. 176 Note to RFC Editor: this section may be removed on publication as an 177 RFC. 179 4. Security Considerations 181 Security considerations are enumerated in [I-D.ietf-rtcweb-security]. 183 5. Acknowledgements 185 This document is based on earlier versions embedded in 186 [I-D.ietf-rtcweb-overview], which were the results of contributions 187 from many RTCWEB WG members. 189 6. References 191 6.1. Normative References 193 [I-D.ietf-mmusic-sctp-sdp] 194 Loreto, S. and G. Camarillo, "Stream Control Transmission 195 Protocol (SCTP)-Based Media Transport in the Session 196 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 197 (work in progress), June 2013. 199 [I-D.ietf-rtcweb-data-channel] 200 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 201 Channels", draft-ietf-rtcweb-data-channel-05 (work in 202 progress), July 2013. 204 [I-D.ietf-rtcweb-qos] 205 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 206 other packet markings for RTCWeb QoS", 207 draft-ietf-rtcweb-qos-00 (work in progress), October 2012. 209 [I-D.ietf-rtcweb-rtp-usage] 210 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 211 Communication (WebRTC): Media Transport and Use of RTP", 212 draft-ietf-rtcweb-rtp-usage-07 (work in progress), 213 July 2013. 215 [I-D.ietf-rtcweb-security] 216 Rescorla, E., "Security Considerations for WebRTC", 217 draft-ietf-rtcweb-security-05 (work in progress), 218 July 2013. 220 [I-D.ietf-rtcweb-security-arch] 221 Rescorla, E., "WebRTC Security Architecture", 222 draft-ietf-rtcweb-security-arch-07 (work in progress), 223 July 2013. 225 [I-D.ietf-tsvwg-sctp-dtls-encaps] 226 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 227 Encapsulation of SCTP Packets", 228 draft-ietf-tsvwg-sctp-dtls-encaps-01 (work in progress), 229 July 2013. 231 [I-D.nandakumar-rtcweb-stun-uri] 232 Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- 233 Huguenin, "URI Scheme for Session Traversal Utilities for 234 NAT (STUN) Protocol", draft-nandakumar-rtcweb-stun-uri-05 235 (work in progress), July 2013. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 241 (ICE): A Protocol for Network Address Translator (NAT) 242 Traversal for Offer/Answer Protocols", RFC 5245, 243 April 2010. 245 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 246 Security (DTLS) Extension to Establish Keys for the Secure 247 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 249 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 250 Relays around NAT (TURN): Relay Extensions to Session 251 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 253 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 254 around NAT (TURN) Extensions for TCP Allocations", 255 RFC 6062, November 2010. 257 6.2. Informative References 259 [I-D.hutton-rtcweb-nat-firewall-considerations] 260 Stach, T., Hutton, A., and J. Uberti, "RTCWEB 261 Considerations for NATs, Firewalls and HTTP proxies", 262 draft-hutton-rtcweb-nat-firewall-considerations-01 (work 263 in progress), June 2013. 265 [I-D.ietf-rtcweb-overview] 266 Alvestrand, H., "Overview: Real Time Protocols for Brower- 267 based Applications", draft-ietf-rtcweb-overview-07 (work 268 in progress), August 2013. 270 [I-D.jesup-rtcweb-data-protocol] 271 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 272 Protocol", draft-jesup-rtcweb-data-protocol-04 (work in 273 progress), February 2013. 275 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 276 Peer (P2P) Communication across Network Address 277 Translators (NATs)", RFC 5128, March 2008. 279 Appendix A. Change log 281 A.1. Changes from -00 to -01 283 o Clarified DSCP requirements, with reference to -qos- 285 o Clarified "symmetric NAT" -> "NATs which perform endpoint- 286 dependent mapping" 288 o Made support of TURN over TCP mandatory 290 o Made support of TURN over TLS a MAY, and added open question 292 o Added an informative reference to -firewalls- 294 o Called out that we don't make requirements on HTTP proxy 295 interaction (yet) 297 Author's Address 299 Harald Alvestrand 300 Google 302 Email: harald@alvestrand.no