idnits 2.17.1 draft-alvestrand-rtcweb-gateways-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 240 lines 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 (March 09, 2015) is 3330 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-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWeb Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Standards Track U. Rauschenbach 5 Expires: September 10, 2015 Nokia Networks 6 March 09, 2015 8 WebRTC Gateways 9 draft-alvestrand-rtcweb-gateways-02 11 Abstract 13 This document specifies conformance requirements for a class of 14 WebRTC-compatible endpoints called "WebRTC gateways", which 15 interconnect between WebRTC endpoints and devices that are not WebRTC 16 endpoints. 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 September 10, 2015. 41 Copyright Notice 43 Copyright (c) 2015 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 59 1.1. Implications of the gateway environment 60 1.2. Signalling model 61 2. WebRTC non-browser requirements that can be relaxed 62 3. Additional WebRTC gateway requirements 63 4. IANA Considerations 64 5. Security Considerations 65 6. Acknowledgements 66 7. Change history 67 8. Normative References 68 Authors' Addresses 70 1. Introduction 72 The WebRTC model described in [I-D.ietf-rtcweb-overview] is focused 73 on direct browser to browser communication as its primary use case. 74 Nevertheless, it is clearly interesting to have WebRTC endpoints 75 connect to other types of devices, including but not limited to SIP 76 phones, legacy phones, CLUE-based teleconferencing systems, XMPP- 77 based conferencing systems, and entirely proprietary devices or 78 systems. 80 WebRTC gateways are a specific type of WebRTC-compatible endpoints 81 which enable the exchange of media streams between WebRTC endpoints 82 on one side, and the other types of devices mentioned above on the 83 other side. 85 This document describes the requirements that need to be placed on 86 such gateways, both the requirements on WebRTC endpoints that can be 87 relaxed and the additional requirements that need to be applied. 89 A WebRTC gateway is a WebRTC-compatible endpoint, and will thus not 90 be conformant with all requirements for a WebRTC endpoint (it does 91 not do everything a WebRTC endpoint does), but is able to 92 interoperate with WebRTC endpoints. 94 1.1. Implications of the gateway environment 96 A gateway will be limited in the functionality it can offer by the 97 system or class of devices it is gatewaying to. For instance, a 98 gateway into the telephone system will not be able to relay data or 99 video, no matter how much it is required. Therefore, a number of 100 functions that are mandatory to support in WebRTC endpoints are not 101 mandatory on gateways; the requirement on the gateway is that it is 102 able to negotiate those features away correctly. 104 1.2. Signalling model 106 The WebRTC model is that signalling is outside the scope of the 107 specification. This document does not change that. 109 Nevertheless, any practical gateway needs to deal with signalling. 110 For that, this document assumes that the overall system consists of 111 an application running in the WebRTC browser, possibly one or more 112 signalling relays that mediate signalling and thereby enable 113 communication between the application and the gateway, and the actual 114 gateway that is responsible for handling the media flows. 116 The application, the signalling relays (if any) and the gateway 117 together need to be able to: 119 o adhere to the offer/answer semantics 121 o deal with the description of configuration coming from the 122 browser; this is specified in SDP format in the WebRTC browser API 124 o generate the information that is needed by the browser to set up 125 the session, and express that information in the form of SDP. 127 The shorthand notation "The gateway MUST/SHOULD/MAY support " used below means that an application running in the 129 Web browser, the signalling relays, and the gateway together 130 MUST/SHOULD/MAY support this functionality; it is not a requirement 131 that this happens at the media gateway itself. 133 2. WebRTC non-browser requirements that can be relaxed 135 WebRTC gateways are intended to communicate with WebRTC endpoints. 136 WebRTC gateways are no User Agents. They are therefore expected to 137 conform to the requirements for WebRTC non-browsers in [I-D.ietf- 138 rtcweb-overview], with the exceptions defined in this section. 140 Since a gateway is expected to be deployed where it can be reached 141 with a static IP address (as seen from the client), a WebRTC gateway 142 does not need to support full ICE; it therefore MAY implement ICE- 143 Lite only. 145 ICE-Lite implementations do not send consent checks, so a gateway MAY 146 choose not to send consent checks too, but MUST respond to consent 147 checks it receives. 149 A gateway is expected to not need to hide its location, so it does 150 not need to support functionality for operating only via a TURN 151 server; instead it MAY choose to produce Host ICE candidates only. 153 If a gateway serves as a media relay into another RTP domain, it MAY 154 choose to support only features available in that network. This 155 means that it MAY not (need to) support Bundle and any of the RTP/ 156 RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the 157 gateway MUST support DTLS-SRTP, since this is required for 158 interworking with WebRTC endpoints. 160 If a gateway serves as a media relay into a network or to devices not 161 implementing the WebRTC Datachannel, it MAY choose to not support the 162 Datachannel. 164 3. Additional WebRTC gateway requirements 166 (nothing yet) 168 4. IANA Considerations 170 This document makes no request of IANA. 172 Note to RFC Editor: this section may be removed on publication as an 173 RFC. 175 5. Security Considerations 177 A WebRTC gateway may operate in two security modes: Security-context 178 termination and security-context relaying. 180 Relaying is only possible where signed and encrypted content can be 181 passed through unchanged, and where keys can be exchanged directly 182 between the endpoints. 184 When the gateway terminates the security context, it means that the 185 WebRTC user has to place trust in the gateway to perform all 186 verification of identity and protection of content in the realm on 187 the other side of the gateway; there is no way the end-user can 188 detect a man-in-the-middle attack, an identity spoofing attack or a 189 recording done at the gateway. For many scenarios, this is not going 190 to be seen as a problem, but needs to be considered when one decides 191 to use a gatewayed service. 193 6. Acknowledgements 195 Several comments from Christer Holmberg were included. 197 7. Change history 199 Changes from draft-alvestrand-rtcweb-gateways-00 201 o Aligned terminology with draft-rtcweb-overview-12 203 o Rewrote text on signaling to improve clarity 205 o Editorial nits 207 Changes from draft-alvestrand-rtcweb-gateways-01 209 o Aligned terminology with draft-rtcweb-overview-13 ("non-browser") 211 o Nits 213 8. Normative References 215 [I-D.ietf-rtcweb-overview] 216 Alvestrand, H., "Overview: Real Time Protocols for 217 Browser-based Applications", draft-ietf-rtcweb-overview-13 218 (work in progress), November 2014. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 Authors' Addresses 225 Harald Alvestrand 226 Google 228 Email: harald@alvestrand.no 230 Uwe Rauschenbach 231 Nokia Networks 233 Email: uwe.rauschenbach@nokia.com