Skip to main content

STUN Usage for Consent Freshness
draft-muthu-behave-consent-freshness-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Muthu Arul Perumal , Dan Wing , Hadriel Kaplan
Last updated 2012-03-04
Replaced by draft-ietf-rtcweb-stun-consent-freshness, RFC 7675
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-muthu-behave-consent-freshness-00
Behave                                                Muthu A M. Perumal
Internet-Draft                                                   D. Wing
Intended status: Standards Track                            R. Ram Mohan
Expires: September 5, 2012                                 Cisco Systems
                                                               H. Kaplan
                                                             Acme Packet
                                                           March 4, 2012

                    STUN Usage for Consent Freshness
                draft-muthu-behave-consent-freshness-00

Abstract

   This document describes a STUN usage that enables WebRTC
   implementations to verify the peer consent for continuing to receive
   traffic on a candidate pair ICE is using for a media component after
   session establishment.  Verification of peer consent is necessary to
   ensure that a malicious JavaScript cannot use the browser as a
   platform for launching attacks.  This form of consent verification
   also serves the purpose of refreshing NAT bindings.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 September 5, 2012.

Copyright Notice

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

Perumal, et al.         Expires September 5, 2012               [Page 1]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Design Considerations . . . . . . . . . . . . . . . . . . . . . 4
   5.  STUN Consent Method . . . . . . . . . . . . . . . . . . . . . . 4
   6.  STUN Consent Method Processing  . . . . . . . . . . . . . . . . 5
     6.1.  Generating a Consent Request  . . . . . . . . . . . . . . . 5
     6.2.  Receiving a Consent Request . . . . . . . . . . . . . . . . 5
     6.3.  Generating a Consent Response . . . . . . . . . . . . . . . 6
     6.4.  Receiving a Consent Response  . . . . . . . . . . . . . . . 6
   7.  Performing Consent Freshness  . . . . . . . . . . . . . . . . . 6
     7.1.  Generating Consent Freshness Request  . . . . . . . . . . . 6
   8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.2.  Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Generating Consent Freshness Response . . . . . . . . . . . . . 7
   10. SDP Extension for Consent Freshness . . . . . . . . . . . . . . 7
   11. Interaction with Keepalives used for Refreshing NAT
       Bindings  . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   12. Open Items  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   13. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8
   16. Normative References  . . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Perumal, et al.         Expires September 5, 2012               [Page 2]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

1.  Introduction

   Consent verification is the mechanism using which WebRTC
   implementations can verify the peer consent for receiving traffic on
   candidate media transport addresses.  This has two parts

   1.  Verifying peer consent for receiving traffic on candidate media
       transport addresses at session establishment.
   2.  Verifying peer consent for continuing to receive traffic on
       candidate media transport addresses after session establishment.

   WebRTC implements are required to perform STUN connectivity checks at
   session establishment as part of ICE procedures [RFC5245].  This
   takes care of the first part of the consent verification described
   above.

   After session establishment ICE requires STUN Binding indications to
   be used for refreshing NAT bindings for a candidate pair ICE is using
   for a media component.  Since a STUN Binding indication does not
   evoke a response, it cannot be used for the second part of the
   consent verification describes above.

   This document defines a new STUN method, Consent and describes a STUN
   usage based on STUN Consent request/response to enable verifying peer
   consent for continuing to receive traffic on a candidate pair ICE is
   using for a media component after session establishment.  This usage
   also serves the purpose of refreshing NAT bindings for that candidate
   pair.

2.  Terminology

   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 [RFC2119].

3.  Definitions

   Consent Freshness:  It is the mechanism of verifying peer consent for
      continuing to receive traffic on a candidate pair ICE is using for
      a media component after ICE has concluded.  This document uses
      completion of session establishment synonymous with the conclusion
      of ICE.

Perumal, et al.         Expires September 5, 2012               [Page 3]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

   Transport Address:  The combination of an IP address and port number
      (such as a UDP or TCP port number).

4.  Design Considerations

   As described in the Introduction, STUN indications are not suitable
   for performing consent freshness.  Hence, performing consent
   freshness requires the use of STUN request/response.

   ICE requires the usage of message integrity with STUN using its
   short-term credential mechanism.  The need for this mechanism goes
   beyond just security and is required for the correct operation of the
   ICE connectivity check procedures; without message integrity the
   connectivity checks can yield false positives, as described in
   Appendix B section B.4 of the ICE specification.  However, this
   problem is not applicable for consent freshness, since consent
   freshness is performed only after ICE concludes.

   One of the reasons for ICE choosing STUN Binding indications for
   keepalives is because Binding indication allows integrity to be
   disabled, allowing for better performance.  This is useful for large-
   scale endpoints, such as PSTN gateways and SBCs as described in
   Appendix B section B.10 of the ICE specification.

   STUN requires the 96 bits transaction ID to be uniformly and randomly
   chosen from the interval 0 .. 2**96-1, and be cryptographically
   random.  This is deemed sufficient for consent freshness from a
   security perspective.

   Considering these aspects, STUN request/response without the message
   integrity and short/long-term credential mechanisms have been chosen
   for consent freshness in this document.  In addition, in order to
   ensure that this STUN usage does not leave an existing ICE
   implementation broken, this document chooses to define a new STUN
   method, Consent to be used for consent freshness.

5.  STUN Consent Method

   The STUN message type field from the STUN specification [RFC5389] is
   shown below

Perumal, et al.         Expires September 5, 2012               [Page 4]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

                           2 3 4 5 6 7 8 9 A B C D E F

                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          |M|M|M|M|M|C|M|M|M|C|M|M|M|M|
                          |b|a|9|8|7|1|6|5|4|0|3|2|1|0|
                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Format of STUN Message Type Field

   Here the bits in the message type field are shown as most significant
   (Mb) through least significant (M0).  C1 and C0 represent a 2-bit
   encoding of the class.  Mb through M0 represent a 12-bit encoding of
   the method.  The Consent method is encoded as 0b000000000010.

   A Consent request has class=0b00 (request) and method=0b000000000010
   (Consent) and is encoded into the first 16 bits of the STUN header as
   0x0002.

   A Consent success response has class=0b10 (success response) and
   method=0b000000000010 (Consent) and is encoded into the first 16 bits
   of the STUN header as 0x0102.

   A Consent error response has class=0b11 (error response) and
   method=0b000000000010 (Consent) and is encoded into the first 16 bits
   of the STUN header as 0x0112.

   A Consent indication has class=0b01 (indication) and
   method=0b000000000010 (Consent) and is encoded into the first 16 bits
   of the STUN header as 0x0012.

6.  STUN Consent Method Processing

   Processing of the STUN Consent method is similar to the processing of
   the STUN Binding method except that the procedures pertaining to the
   message integrity and short/long-term credential mechanisms are not
   applicable.  In particular, the USERNAME and MESSAGE-INTEGRITY
   attributes are not included in a Consent request or response.

6.1.  Generating a Consent Request

   TBD

6.2.  Receiving a Consent Request

   TBD

Perumal, et al.         Expires September 5, 2012               [Page 5]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

6.3.  Generating a Consent Response

   TBD

6.4.  Receiving a Consent Response

   TBD

7.  Performing Consent Freshness

   The consent freshness described here is performed using STUN Consent
   request/response after ICE concludes.  The FINGERPRINT mechanism MUST
   be used for consent freshness.

7.1.  Generating Consent Freshness Request

   A STUN agent generates a consent freshness request by constructing a
   STUN Consent request.  If there has been no STUN Consent request
   generated on a candidate pair ICE is using for a media component for
   Tc seconds, the agent MUST generate a consent freshness request.

   If the transaction fails because all retransmissions of the request
   time out or an ICMP error or a Consent failure received, then the
   agent checks if Tm seconds have elapsed since the transaction began.
   If Tm seconds have elapsed, then consent freshness is considered to
   have failed in the direction from the agent to its peer.  Otherwise,
   the agent retries the Consent request after Tc seconds.

   If the second transaction also fails, then the agent checks if Tm
   seconds have elapsed since the first transaction began.  If Tm
   seconds have elapsed, then consent freshness is considered to have
   failed in the direction from the agent to its peer.  Otherwise, the
   agent retries the Consent request again after Tc seconds.

   If the third transaction also fails, then consent freshness is
   considered to have failed in the direction from the agent to its
   peer.

   If consent freshness fails either because of Tm seconds elapsing or
   the all retries exhausting, the agent MUST stop sending traffic on
   that candidate pair.  However, the agent MAY continue to receive
   traffic from the peer.  At this point, if a consent freshness
   initiated from the peer succeeds, the agent MAY initiate a consent
   freshness request.  If this consent freshness request succeeds, the
   agent MAY start sending traffic to the peer on this candidate pair.

   Both Tc and Tm SHOULD be configurable.  Tc SHOULD have a default of

Perumal, et al.         Expires September 5, 2012               [Page 6]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

   15 seconds and MUST NOT be configured to less than 15 seconds.  Tm
   SHOULD have a default of 30 seconds.

8.  Examples

   The examples in this section show how consent freshness requests are
   retried with Tc and Tm set to their default values.

8.1.  Example 1

   Suppose the consent freshness requests generated by an agent evoke an
   ICM error almost immediately every time.  Then the agent will retry
   the requests at times 15 seconds and 30 seconds approximately before
   concluding the consent freshness to have failed in the direction from
   the agent to its peer.

8.2.  Example 2

   Suppose the STUN RTO (Retransmission TimeOut) is 500 ms.  Then an
   agent initiating consent freshness will retransmit the request at 500
   ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms.  If the agent
   has not received a response after 39500 ms, the agent will consider
   the transaction to have timed out, as described in section 7.2.1 of
   the STUN specification.  At this point, since Tm seconds have elapsed
   since the transaction began, the agent will consider the consent
   freshness to have failed in the direction from the agent to its peer.

9.  Generating Consent Freshness Response

   A STUN agent receiving a consent freshness request for a candidate
   pair ICE is using for a media component MUST generate a STUN Consent
   response.

10.  SDP Extension for Consent Freshness

   ICE provides the a=ice-options SDP attribute for defining new ICE
   extensions in a backward compatible manner.  This document defines a
   new ICE extension "consent" to negotiate the consent freshness usage
   described in this document.

   An offerer that supports ICE and wishes to perform the consent
   freshness as described in this document MUST include the a=ice-
   options:consent session level SDP attribute in the SDP offer.

   An answerer that agrees to perform consent freshness as described in

Perumal, et al.         Expires September 5, 2012               [Page 7]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

   this document MUST include the a=ice-options:consent session level
   SDP attribute in the SDP answer.

   If the SDP offer does not contain the a=ice-options:consent session
   level SDP attribute, the SDP answer MUST NOT contain the a=ice-
   options:consent session level SDP attribute.

11.  Interaction with Keepalives used for Refreshing NAT Bindings

   An implementation that uses the consent freshness described in this
   document has no need to also perform the keepalives described in ICE
   [RFC5245] or RTP keepalive [RFC6263], as they both force recurring
   messages to be sent over the UDP port used by RTP.  Thus, an
   implementation that uses the consent freshness described in this
   document SHOULD NOT also do the keepalives described in ICE [RFC5245]
   or RTP keepalives [RFC6263] for the UDP port used for RTP.

   The RTCP port, if different from the RTP port, does not need consent
   freshness (does it?) and continues to use the keepalives described in
   ICE [RFC5245] or RTP keepalives [RFC6263] to refresh NAT bindings.

12.  Open Items

   1.  This document describes a consent freshness mechanism for an ICE
       usage.  Is there a need for consent freshness even when ICE is
       not used (certainly not for WebRTC where ICE is mandatory)?
   2.  If the RTCP port is different from the RTP port, does the RTCP
       port need consent freshness?  It looks unlikely given that RTCP
       is typically rate limited.

13.  Security Considerations

   TBD

14.  IANA Considerations

   TBD

15.  Acknowledgement

   TBD

Perumal, et al.         Expires September 5, 2012               [Page 8]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

16.  Normative References

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

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

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

   [RFC6263]  Marjou, X. and A. Sollaud, "Application Mechanism for
              Keeping Alive the NAT Mappings Associated with RTP / RTP
              Control Protocol (RTCP) Flows", RFC 6263, June 2011.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

Authors' Addresses

   Muthu Arul Mozhi Perumal
   Cisco Systems
   Cessna Business Park
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: mperumal@cisco.com

   Dan Wing
   Cisco Systems
   821 Alder Drive
   Milpitas, California  95035
   USA

   Email: dwing@cisco.com

Perumal, et al.         Expires September 5, 2012               [Page 9]
Internet-Draft      STUN Usage for Consent Freshness          March 2012

   Ram Mohan R
   Cisco Systems
   Cessna Business Park
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com

   Hadriel Kaplan
   Acme Packet

   Email: hkaplan@acmepacket.com

Perumal, et al.         Expires September 5, 2012              [Page 10]