[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-rtcweb-stun-consent-freshness

RTCWEB                                                        M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                                 D. Wing
Expires: May 24, 2014                                        C. Jennings
                                                                   Cisco
                                                       November 20, 2013


       Gaining and Maintaining Consent for Real-Time Applications
                    draft-thomson-rtcweb-consent-00

Abstract

   This document describes how DTLS provides a WebRTC application a
   clear indication that a receiver is willing to receive packets.
   Mechanisms are described for maintaining that consent are described.

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 May 24, 2014.

Copyright Notice

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



Thomson, et al.           Expires May 24, 2014                  [Page 1]


Internet-Draft               Receive Consent               November 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   2
   2.  Obtaining and Maintaining Receive Consent . . . . . . . . . .   2
     2.1.  Consent in WebRTC . . . . . . . . . . . . . . . . . . . .   3
     2.2.  The Role of ICE . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Relationship with Connection Liveness . . . . . . . . . .   4
   3.  Application Layer Protocol Identifiers  . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In addition to establishing connectivity, Interactive Connectivity
   Establishment (ICE) [RFC5245] has been used in real-time applications
   to establish that a peer is willing to receive packets.

   This document describes how Datagram Transport Layer Security (DTLS)
   [RFC6347] is sufficient for establishing consent to receive packets,
   plus how this consent can be continuously refreshed.

   This also uses Application-Layer Protocol Negotiation (ALPN)
   [I-D.ietf-tls-applayerprotoneg] to restrict that consent to specific
   uses.  Application protocol tokens are defined for the Real-Time
   Protocol (RTP) [RFC3550] over DTLS-SRTP [RFC5764], WebRTC data
   channels [I-D.ietf-rtcweb-data-channel] and a multiplexed combination
   of these two protocols.

1.1.  Conventions and Terminology

   At times, this document falls back on shorthands for establishing
   interoperability requirements on implementations: the capitalized
   words "MUST", "SHOULD" and "MAY".  These terms are defined in
   [RFC2119].

2.  Obtaining and Maintaining Receive Consent

   An endpoint MUST NOT send application data (in WebRTC, RTP or SCTP
   data) on a DTLS connection unless the receiving endpoint consents to
   receive the data.





Thomson, et al.           Expires May 24, 2014                  [Page 2]


Internet-Draft               Receive Consent               November 2013


   An endpoint that initiates or responds to a DTLS handshake that
   negotiates a specific application layer protocol (see Section 3)
   explicitly consents to receive packets containing the described
   protocol.

   Consent expires after a fixed amount of time.  Explicit consent to
   receive is indicated by the receiving endpoint sending authenticated
   packets from the inverted 5-tuple.  An endpoint uses the receipt of
   packets as an indication that the remote endpoint still consents to
   receive data.

   Any packet received from the inverted 5-tuple refreshes consent if
   the packet is successfully validated by the protocol's authentication
   check (for instance, a MAC).  Any DTLS message is sufficient to
   refresh consent, since these contain a MAC.  For DTLS-SRTP [RFC5764],
   receipt of an authenticated SRTP packet is sufficient.

   Consent is ended immediately by receipt of a an authenticated message
   that closes the connection (for instance, a TLS fatal alert).

   Receipt of an unauthenticated end-of-session message (e.g., TCP FIN)
   does not indicate loss of consent.  Thus, an endpoint receiving an
   unauthenticated end-of-session message SHOULD continue sending media
   (over connectionless transport) or attempt to re-establish the
   connection (over connection-oriented transport) until consent expires
   or it receives an authenticated message revoking consent.

2.1.  Consent in WebRTC

   WebRTC applications MUST cease transmission on a connection if they
   have not received any valid, authenticated packets for 30 seconds.

   WebRTC applications that intend to maintain consent MUST send an
   authenticated packet at least every 10 seconds.  If there is no
   application data to send, the DTLS heartbeat extension [RFC6520] MUST
   be sent to maintain consent.  This reduces the probability that
   transient network failures cause consent expiration.

2.2.  The Role of ICE

   Given that DTLS is used to establish and maintain consent, ICE is
   only used to test and nominate candidate pairs.  This allows for the
   use of DTLS without ICE, though this is unlikely to work for
   endpoints with poor connectivity.

   If ICE is not employed, a DTLS server SHOULD use the denial of
   service countermeasures described in Section 4.2.1 of [RFC6347];
   specifically the "HelloVerifyRequest" and the cookie that it carries.



Thomson, et al.           Expires May 24, 2014                  [Page 3]


Internet-Draft               Receive Consent               November 2013


2.3.  Relationship with Connection Liveness

   A connection is considered "live" if packets are received from a
   remote endpoint within an application-dependent period.

   A WebRTC application can request a notification when there are no
   packets received for a certain period.  Similarly, an application can
   request that heartbeats are sent after an interval shorter than 10
   seconds.  These two time intervals might be controlled by the same
   configuration item.

   Sending heartbeats at a high rate could allow a malicious application
   to generate congestion.  A WebRTC application MUST NOT be able to
   send heartbeats at a rate higher than 1 per second.

3.  Application Layer Protocol Identifiers

   The following ALPN identifiers are defined:

   RTP (0x52 0x54 0x50):  This token indicates that DTLS-SRTP [RFC5764]
      is acceptable or selected.

   SCTP (0x53 0x43 0x54 0x50):  This token indicates that WebRTC Data
      Channels [I-D.ietf-rtcweb-data-channel] is acceptable or accepted.
      The DTLS record-layer carries encapsulated Stream Control
      Transmission Protocol (SCTP) [RFC4960] packets as described in
      [I-D.ietf-tsvwg-sctp-dtls-encaps].

   RTP+SCTP (0x52 0x54 0x50 0x2b 0x53 0x43 0x54 0x50):  This token
      indicates that both DTLS-SRTP [RFC5764] and WebRTC Data Channels
      [I-D.ietf-rtcweb-data-channel] are acceptable or selected.  The
      DTLS record-layer carries encapsulated SCTP packets as described
      in [I-D.ietf-tsvwg-sctp-dtls-encaps]; this is multiplexed with
      SRTP [RFC3711] packets as described in [RFC5764].

   An application that can use a multiplexed combination of SRTP and
   SCTP MUST select "RTP+SCTP" if it is available, even if it is not
   using both protocols initially.  This avoids any need to renegotiate
   application layer protocols as usage needs change.

4.  Security Considerations

   This document defines a security mechanism.

   Consent does not establish any bounds on the volume of packets that a
   receiver is willing to accept.  A receiver that receives packets at a
   rate in excess of what it is willing to tolerate can close the
   connection.  If the close message is lost, this can result in



Thomson, et al.           Expires May 24, 2014                  [Page 4]


Internet-Draft               Receive Consent               November 2013


   unwanted data being received until consent expires (i.e., 30
   seconds).

   SRTP is encrypted and authenticated with symmetric keys; that is,
   both sender and receiver know the keys.  With two party sessions,
   receipt of an authenticated packet from the single remote party is a
   strong assurance the packet came from that party.  However, when a
   session involves more than two parties, all of whom know each others
   keys, any of those parties could have sent (or spoofed) the packet.
   Such shared key distributions are possible with some MIKEY [RFC3830]
   modes, Security Descriptions [RFC4568], and EKT
   [I-D.ietf-avtcore-srtp-ekt].

5.  IANA Considerations

   This document registers three identifiers in the "Application Layer
   Protocol Negotiation (ALPN) Protocol IDs" established by
   [I-D.ietf-tls-applayerprotoneg].

   Protocol:  RTP over DTLS-SRTP

   Identification Sequence:  0x52 0x54 0x50 ("RTP")

   Specification:  This document.

   Protocol:  WebRTC Data Channels

   Identification Sequence:  0x53 0x43 0x54 0x50 ("SCTP")

   Specification:  This document.

   Protocol:  RTP over DTLS-SRTP multiplexed with WebRTC Data Channels

   Identification Sequence:  0x52 0x54 0x50 0x2b 0x53 0x43 0x54 0x50
      ("RTP+SCTP")

   Specification:  This document.

6.  Acknowledgements

   Muthu Arul Mozhi Perumal, Ram Mohan Ravindranath, Tirumaleswar Reddy,
   and Dan Wing are the authors of the original draft that dealt with
   managing consent.

7.  References

7.1.  Normative References




Thomson, et al.           Expires May 24, 2014                  [Page 5]


Internet-Draft               Receive Consent               November 2013


   [I-D.ietf-rtcweb-data-channel]
              Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data
              Channels", draft-ietf-rtcweb-data-channel-06 (work in
              progress), October 2013.

   [I-D.ietf-tls-applayerprotoneg]
              Friedl, S., Popov, A., Langley, A., and S. Emile,
              "Transport Layer Security (TLS) Application Layer Protocol
              Negotiation Extension", draft-ietf-tls-applayerprotoneg-03
              (work in progress), October 2013.

   [I-D.ietf-tsvwg-sctp-dtls-encaps]
              Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
              Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
              dtls-encaps-02 (work in progress), October 2013.

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS) Heartbeat Extension", RFC 6520, February 2012.

7.2.  Informative References

   [I-D.ietf-avtcore-srtp-ekt]
              McGrew, D. and D. Wing, "Encrypted Key Transport for
              Secure RTP", draft-ietf-avtcore-srtp-ekt-01 (work in
              progress), October 2013.






Thomson, et al.           Expires May 24, 2014                  [Page 6]


Internet-Draft               Receive Consent               November 2013


   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

Authors' Addresses

   Martin Thomson
   Mozilla
   Suite 300
   650 Castro Street
   Mountain View, CA  94041
   US

   Email: martin.thomson@gmail.com


   Dan Wing
   Cisco Systems, Inc.
   510 McCarthy Blvd.
   Milpitas, CA  95035
   US

   Phone: (408) 853 4197
   Email: dwing@cisco.com


   Cullen Jennings
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 421-9990
   Email: fluffy@cisco.com






Thomson, et al.           Expires May 24, 2014                  [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/