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]