idnits 2.17.1 draft-alvestrand-rtcweb-gateways-00.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 (August 15, 2014) is 3536 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 (-19) exists of draft-ietf-rtcweb-overview-10 Summary: 0 errors (**), 0 flaws (~~), 2 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 August 15, 2014 5 Expires: February 16, 2015 7 WebRTC Gateways 8 draft-alvestrand-rtcweb-gateways-00 10 Abstract 12 This document specifies conformance requirements for a class of 13 WebRTC devices called "WebRTC gateways". 15 This type of device forms interconnects between WebRTC browsers and 16 devices that are not WebRTC browsers. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 16, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Implications of the gateway environment . . . . . . . . . 2 60 1.2. Signalling model . . . . . . . . . . . . . . . . . . . . 3 61 2. WebRTC device requirements that can be relaxed . . . . . . . 3 62 3. Additional WebRTC gateway requirements . . . . . . . . . . . 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 The WebRTC model described in [I-D.ietf-rtcweb-overview] is focused 72 on direct browser to browser communication as its primary use case. 73 Nevertheless, it is clearly interesting to have applications that run 74 in WebRTC browsers connect to other types of devices, including but 75 not limited to SIP phones, legacy phones, CLUE-based teleconferencing 76 systems, XMPP-based conferencing systems, and entirely proprietary 77 devices or systems. 79 WebRTC gateways are a specific type of devices which enable the 80 exchange of media streams between WebRTC browsers on one side, and 81 the other types of devices mentioned above on the other side. 83 This document describes the requirements that need to be placed on 84 such gateways, both the requirements on generic WebRTC devices that 85 can be relaxed and the additional requirements that need to be 86 applied. 88 A WebRTC gateway will thus not be conformant with all requirements 89 for a WebRTC device (it does not do everything a WebRTC device does), 90 but is able to interoperate with WebRTC browsers and WebRTC devices. 92 1.1. Implications of the gateway environment 94 A gateway will be limited in the functionality it can offer by the 95 thing it is gatewaying to. For instance, a gateway into the 96 telephone system will not be able to relay data or video, no matter 97 how much it is required. Therefore, a number of functions that are 98 mandatory to support in WebRTC devices are not mandatory on gateways; 99 the requirement on the gateway is that it is able to negotiate those 100 features away correctly. 102 1.2. Signalling model 104 The WebRTC model is that signalling is outside of the specification. 105 This specification does not change that. 107 Nevertheless, any practical gateway needs to deal with signalling, in 108 two senses: 110 o The application, the signalling relays (if any) and the gateway 111 need to be able to, together, adhere to the offer/answer semantics 112 and deal with the description of configuration coming from the 113 browser; this is specified in SDP format in the WebRTC browser 114 API. 116 o The application, the signalling relays (if any) and the gateway 117 need to be able to, together, generate the information that is 118 needed by the browser to set up the session, and express that 119 information in the form of SDP, and adhere to the offer/answer 120 semantics. 122 In this document, the shorthand notation "The gateway MUST/SHOULD/MAY 123 support " is used. This means that an application 124 running in the Web browser, the signalling relays that mediate 125 signalling and thereby enable communication between the application 126 and the gateway, and the gateway together MUST/SHOULD/MAY support 127 this functionality; it is not a requirement that this happen at the 128 media gateway itself. 130 2. WebRTC device requirements that can be relaxed 132 WebRTC gateways are intended to communicate with WebRTC devices; they 133 are therefore expected to conform to the requirements in [I-D.ietf- 134 rtcweb-overview], with the exceptions defined in this section. 136 Since a gateway is expected to be deployed where it can be reached 137 with a static IP address (as seen from the client), a WebRTC gateway 138 does not need to support full ICE; it therefore MAY implement ICE- 139 Lite only. 141 ICE-Lite implementations do not send consent checks, so a gateway MAY 142 choose not to send consent checks too, but MUST respond to 143 connectivity checks it receives. 145 A gateway is expected to not need to hide its location, so it does 146 not need to support functionality for operating only via a TURN 147 server; instead it MAY choose to produce Host ICE candidates only. 149 If a gateway serves as a media relay into another RTP domain, it MAY 150 choose to support only features available in that network. This 151 means that it MAY not (need to) support Bundle and any of the RTP/ 152 RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the 153 gateway MUST support DTLS-SRTP, since this is required for 154 interworking with conformant WebRTC devices. 156 If a gateway serves as a media relay into a network or to devices not 157 implementing the WebRTC Datachannel, it MAY choose to not support the 158 Datachannel. 160 3. Additional WebRTC gateway requirements 162 (nothing yet) 164 4. IANA Considerations 166 This document makes no request of IANA. 168 Note to RFC Editor: this section may be removed on publication as an 169 RFC. 171 5. Security Considerations 173 A WebRTC gateway may operate in two security modes: Security-context 174 termination and security-context relaying. 176 Relaying is only possible when signed and encrypted content can be 177 passed through unchanged, and where keys can be exchanged directly 178 between the endpoints. 180 When the gateway terminates the security context, it means that the 181 WebRTC user has to place trust in the gateway to perform all 182 verification of identity and protection of content in the realm on 183 the other side of the gateway; there is no way the end-user can 184 detect a man-in-the-middle attack, an identity spoofing attack or a 185 recording done at the gateway. For many scenarios, this is not going 186 to be seen as a problem, but needs to be considered when one decides 187 to use a gatewayed service. 189 6. Acknowledgements 191 Several contributions from Uwe Rauschenbach were made in this 192 version, and also some comments from Christer Holmberg. 194 7. Normative References 196 [I-D.ietf-rtcweb-overview] 197 Alvestrand, H., "Overview: Real Time Protocols for 198 Browser-based Applications", draft-ietf-rtcweb-overview-10 199 (work in progress), June 2014. 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 Author's Address 206 Harald Alvestrand 207 Google 209 Email: harald@alvestrand.no