Network Working Group                                      H. Alvestrand
Internet-Draft                                                    Google
Intended status: Standards Track                         August 15, 2014
Expires: February 16, 2015


                            WebRTC Gateways
                  draft-alvestrand-rtcweb-gateways-00

Abstract

   This document specifies conformance requirements for a class of
   WebRTC devices called "WebRTC gateways".

   This type of device forms interconnects between WebRTC browsers and
   devices that are not WebRTC browsers.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 February 16, 2015.

Copyright Notice

   Copyright (c) 2014 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



Alvestrand              Expires February 16, 2015               [Page 1]

Internet-Draft              Abbreviated-Title                August 2014


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Implications of the gateway environment . . . . . . . . .   2
     1.2.  Signalling model  . . . . . . . . . . . . . . . . . . . .   3
   2.  WebRTC device requirements that can be relaxed  . . . . . . .   3
   3.  Additional WebRTC gateway requirements  . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

.  Introduction

   The WebRTC model described in [I-D.ietf-rtcweb-overview] is focused
   on direct browser to browser communication as its primary use case.
   Nevertheless, it is clearly interesting to have applications that run
   in WebRTC browsers connect to other types of devices, including but
   not limited to SIP phones, legacy phones, CLUE-based teleconferencing
   systems, XMPP-based conferencing systems, and entirely proprietary
   devices or systems.

   WebRTC gateways are a specific type of devices which enable the
   exchange of media streams between WebRTC browsers on one side, and
   the other types of devices mentioned above on the other side.

   This document describes the requirements that need to be placed on
   such gateways, both the requirements on generic WebRTC devices that
   can be relaxed and the additional requirements that need to be
   applied.

   A WebRTC gateway will thus not be conformant with all requirements
   for a WebRTC device (it does not do everything a WebRTC device does),
   but is able to interoperate with WebRTC browsers and WebRTC devices.

1.1.  Implications of the gateway environment

   A gateway will be limited in the functionality it can offer by the
   thing it is gatewaying to.  For instance, a gateway into the
   telephone system will not be able to relay data or video, no matter



Alvestrand              Expires February 16, 2015               [Page 2]

Internet-Draft              Abbreviated-Title                August 2014


   how much it is required.  Therefore, a number of functions that are
   mandatory to support in WebRTC devices are not mandatory on gateways;
   the requirement on the gateway is that it is able to negotiate those
   features away correctly.

1.2.  Signalling model

   The WebRTC model is that signalling is outside of the specification.
   This specification does not change that.

   Nevertheless, any practical gateway needs to deal with signalling, in
   two senses:

   o  The application, the signalling relays (if any) and the gateway
      need to be able to, together, adhere to the offer/answer semantics
      and deal with the description of configuration coming from the
      browser; this is specified in SDP format in the WebRTC browser
      API.

   o  The application, the signalling relays (if any) and the gateway
      need to be able to, together, generate the information that is
      needed by the browser to set up the session, and express that
      information in the form of SDP, and adhere to the offer/answer
      semantics.

   In this document, the shorthand notation "The gateway MUST/SHOULD/MAY
   support <SDP function xxx>" is used.  This means that an application
   running in the Web browser, the signalling relays that mediate
   signalling and thereby enable communication between the application
   and the gateway, and the gateway together MUST/SHOULD/MAY support
   this functionality; it is not a requirement that this happen at the
   media gateway itself.

.  WebRTC device requirements that can be relaxed

   WebRTC gateways are intended to communicate with WebRTC devices; they
   are therefore expected to conform to the requirements in [I-D.ietf-
   rtcweb-overview], with the exceptions defined in this section.

   Since a gateway is expected to be deployed where it can be reached
   with a static IP address (as seen from the client), a WebRTC gateway
   does not need to support full ICE; it therefore MAY implement ICE-
   Lite only.

   ICE-Lite implementations do not send consent checks, so a gateway MAY
   choose not to send consent checks too, but MUST respond to
   connectivity checks it receives.




Alvestrand              Expires February 16, 2015               [Page 3]

Internet-Draft              Abbreviated-Title                August 2014


   A gateway is expected to not need to hide its location, so it does
   not need to support functionality for operating only via a TURN
   server; instead it MAY choose to produce Host ICE candidates only.

   If a gateway serves as a media relay into another RTP domain, it MAY
   choose to support only features available in that network.  This
   means that it MAY not (need to) support Bundle and any of the RTP/
   RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the
   gateway MUST support DTLS-SRTP, since this is required for
   interworking with conformant WebRTC devices.

   If a gateway serves as a media relay into a network or to devices not
   implementing the WebRTC Datachannel, it MAY choose to not support the
   Datachannel.

.  Additional WebRTC gateway requirements

   (nothing yet)

.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

.  Security Considerations

   A WebRTC gateway may operate in two security modes: Security-context
   termination and security-context relaying.

   Relaying is only possible when signed and encrypted content can be
   passed through unchanged, and where keys can be exchanged directly
   between the endpoints.

   When the gateway terminates the security context, it means that the
   WebRTC user has to place trust in the gateway to perform all
   verification of identity and protection of content in the realm on
   the other side of the gateway; there is no way the end-user can
   detect a man-in-the-middle attack, an identity spoofing attack or a
   recording done at the gateway.  For many scenarios, this is not going
   to be seen as a problem, but needs to be considered when one decides
   to use a gatewayed service.








Alvestrand              Expires February 16, 2015               [Page 4]

Internet-Draft              Abbreviated-Title                August 2014


.  Acknowledgements

   Several contributions from Uwe Rauschenbach were made in this
   version, and also some comments from Christer Holmberg.

.  Normative References

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for
              Browser-based Applications", draft-ietf-rtcweb-overview-10
              (work in progress), June 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address

   Harald Alvestrand
   Google

   Email: harald@alvestrand.no






























Alvestrand              Expires February 16, 2015               [Page 5]