draft-ietf-rtcweb-stun-consent-freshness-01.txt   draft-ietf-rtcweb-stun-consent-freshness-02.txt 
RTCWEB Muthu. Perumal
RTCWEB M. Perumal
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Standards Track R. Ravindranath Intended status: Standards Track R. Ravindranath
Expires: September 25, 2014 T. Reddy Expires: October 13, 2014 T. Reddy
Cisco Systems Cisco Systems
March 24, 2014 M. Thomson
Mozilla
April 11, 2014
STUN Usage for Consent Freshness STUN Usage for Consent Freshness
draft-ietf-rtcweb-stun-consent-freshness-01 draft-ietf-rtcweb-stun-consent-freshness-02
Abstract Abstract
Verification of peer consent before sending traffic is necessary in To prevent sending excessive traffic to an endpoint, periodic consent
WebRTC deployments to ensure that a malicious JavaScript cannot use needs to be obtained from that remote endpoint.
the browser as a platform for launching attacks. A related problem
is session liveness. WebRTC application may want to detect
connection failure and take appropriate action.
This document describes how a WebRTC browser can verify peer consent This document describes a consent mechanism using a new STUN usage.
to continue sending traffic and detect connection failure. This same mechanism can also determine connection loss ("liveness")
with a remote peer.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 25, 2014. This Internet-Draft will expire on October 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
5. W3C API Implications . . . . . . . . . . . . . . . . . . . . 5 5. Connection Liveness . . . . . . . . . . . . . . . . . . . . . 4
6. Interaction with Keepalives used for Refreshing NAT Bindings 5 6. DiffServ Treatment for Consent packets . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. W3C API Implications . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 5 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
To prevent attacks on WebRTC peers, WebRTC browsers have to ensure To prevent attacks on peers, RTP endpoints have to ensure the remote
the remote peer wants to receive traffic. This is performed both peer wants to receive traffic. This is performed both when the
when the session is first established to the remote peer (using ICE session is first established to the remote peer using ICE
connectivity checks), and periodically for the duration of the connectivity checks, and periodically for the duration of the session
session (using the procedure defined in this document). using the procedures defined in this document.
When a session is first established, WebRTC implementations are When a session is first established, WebRTC implementations are
required to perform STUN connectivity checks as part of ICE required to perform STUN connectivity checks as part of ICE
[RFC5245]. That initial consent is not described further in this [RFC5245]. That initial consent is not described further in this
document. document and it is assumed that ICE is being used for that initial
consent.
Related to consent is loss of connectivity ("liveness"). WebRTC Related to consent is loss of connectivity ("liveness"). Many
applications want notification of connection failure to take applications want notification of connection loss to take appropriate
appropriate actions (e.g., alert the user, try switching to a actions (e.g., alert the user, try switching to a different
different interface). interface).
This document describes a new STUN usage with a request and response This document describes a new STUN usage with a request and response
which verifies the remote peer consents to receive traffic, and messages which verifies the remote peer's consent to receive traffic,
detects loss of liveness. To meet the security needs of consent, the and can also detect loss of liveness.
JavaScript application has no control over the consent requests or
the requirement to receive a consent response. However, the
JavaScript does get notification of consent failure and loss of
connectivity.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Consent: It is the mechanism of obtaining permission from the peer Consent: It is the mechanism of obtaining permission to send traffic
to send traffic on a candidate pair. to a certain transport address. This is usually obtained via ICE.
Consent Freshness: It is the mechanism of obtaining permission from Consent Freshness: Permission to continue sending traffic to a
the peer to continue sending traffic on a nominated candidate pair certain transport address. This is performed by the procedure
after ICE has concluded. described in this document.
Session Liveness: It is the mechanism of detecting connectivity on a Session Liveness: Detecting loss of connectivity to a certain
nominated candidate pair after ICE has concluded. transport address. This is performed by the procedure described
in this document.
Transport Address: The combination of an IP address and port number Transport Address: The remote peer's IP address and (UDP or TCP)
(such as a UDP or TCP port number). port number.
3. Design Considerations 3. Design Considerations
Although ICE requires periodic keepalive traffic to be sent in order Although ICE requires periodic keepalive traffic to keep NAT bindings
to keep NAT bindings alive (Section 10 of [RFC5245], [RFC6263]), alive (Section 10 of [RFC5245], [RFC6263]), those keepalives are sent
those keepalives are send-and-forget, and do not evoke a response. A as STUN Indications which are send-and-forget, and do not evoke a
response is necessary both for consent to continue sending traffic, response. A response is necessary both for consent to continue
as well as to ensure connectivity. Thus, we need a request/response sending traffic, as well as to verify session liveness. Thus, we
mechanism. need a request/response mechanism for consent freshness. ICE can be
used for that mechanism because ICE already requires ICE agents
continue listening for ICE messages, as described in section 10 of
[RFC5245].
Though ICE specifies STUN Binding indications to be used for 4. Solution Overview
keepalives, it requires that an agent be prepared to receive
connectivity check as well. If a connectivity check is received, a
response is generated and there is no impact on ICE processing, as
described in section 10 of [RFC5245].
The above considerations suggest that STUN Binding request/response A WebRTC browser performs a combined consent freshness and session
is most suitable for performing consent freshness. liveness test using STUN request/response as described below:
4. Solution Overview An endpoint MUST NOT send application data (in WebRTC this means RTP
or SCTP data) on an ICE-initiated connection unless the receiving
endpoint consents to receive the data. After a successful ICE
connectivity check on a particular transport address, subsequent
consent MUST be obtained following the procedure described in this
document. The consent expires after a fixed amount of time.
Explicit consent to send is indicated by:
Consent freshness serves as a circuit breaker (so that if the path or 1. Sending an ICE binding request to the remote peer's Transport
remote peer fails the WebRTC browser stops sending all traffic on Address and receiving a matching and authenticated ICE binding
that remote peer), determining session liveness serves the purpose of response from the inverted remote peer's Transport Address.
notifying the application of connectivity failure so that the
application can take appropriate action.
The solution uses three values: These ICE binding request/response are authenticated using the
same short- term credentials as the initial ICE exchange, but
using a new (fresh) transaction-id each time consent needs to be
refresh. Implementations MUST obtain fresh consent before their
existing consent expires. When obtaining fresh consent a STUN
connectivity check (or response) could be lost, and re-
transmissions MUST use the same STUN transaction-id, and re-
transmissions MUST NOT be sent more frequently than every 500ms
or the smoothed round-trip time (from previous consent freshness
checks or RTP round-trip time), whichever is less. For the
purposes of this document, receipt of an ICE response with the
matching transaction-id of its request with a valid MESSAGE-
INTEGRITY is considered an authenticated packet.
1. A consent timer, Tc, whose value is determined by the browser. Consent expires after 15 seconds. That is, if an authenticated
This value MUST be 15 seconds. packet (e.g., DTLS, SRTP, ICE) has not been received from the
inverted 5-tuple after 15 seconds, the application MUST cease
transmission on that 5-tuple.
2. A packet receipt timer, Tr, whose value is determined by the Consent is ended immediately by receipt of a an authenticated message
application, but MUST NOT be shorter than 1 second or longer than that closes the connection (for instance, a TLS fatal alert).
15 seconds, and SHOULD have a default value of 5 seconds.
3. A consent timeout, Tf, which is how many seconds elapse without a Receipt of an unauthenticated end-of-session message (e.g., TCP FIN)
consent response before the browser ceases transmission of media. does not indicate loss of consent. Thus, an endpoint receiving an
Its value MUST be 15 seconds or less, and the value 15 seconds is unauthenticated end-of-session message SHOULD continue sending media
RECOMMENDED. (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.
A WebRTC browser performs a combined consent freshness and session Although receiving authenticated packets is sufficient for consent,
liveness test using STUN request/response as described below: it is still RECOMMENDED to send messages to keep NAT or firewall
bindings alive (see Section 10 of [RFC5245] and [RFC6263]).
Every Tc seconds, the WebRTC browser sends a STUN Binding Request to To meet the security needs of consent, an implementation MUST ensure
the peer. This request MUST use a new, cryptographically random that an application (e.g., Javascript application) is not able to
Transaction ID [RFC4086], and is formatted as for an ICE connectivity obtain or control STUN information relevant to consent, specifically
check [RFC5245]. A valid STUN Binding Response is also formatted as the ICE transaction-id MUST NOT be accessible to upper-level
for an ICE connectivity check [RFC5245]. The STUN Binding Request applications.
and STUN Binding Response are validated as for an ICE connectivity
check [RFC5245]. The difference from ICE connectivity check is that
there is no exponential back off for retransmissions.
If a valid STUN Binding Response is received, the consent timer is 5. Connection Liveness
reset and fires again Tc seconds later.
If a valid STUN Binding Response is not received after 500ms, the A connection is considered "live" if packets are received from a
STUN Binding Request is retransmitted (with the same Transaction ID remote endpoint within an application-dependent period. An
and all other fields). As long as a valid STUN Binding Response is application can request a notification when there are no packets
not received, this retransmission is repeated every 500ms until Tf received for a certain period (configurable).
seconds have elapsed or a valid response is received. If no valid
response is received after Tf seconds, the WebRTC browser MUST quit
transmitting traffic to this remote peer. Considering the default
value of Tf=15 seconds, this means transmission will stop after 30
consent check packets have resulted in no response.
Liveness timer: If no packets have been received on the local port in Similarly, if packets haven't been received within a certain period,
Tr seconds, the WebRTC browser MUST inform the JavaScript that an application can request a consent check (heartbeat) be generated.
connectivity has been lost. The JavaScript application will use this
notification however it desires (e.g., cease transmitting to the
remote peer, provide a notification to the user, etc.). Note the
definition of a received packet is liberal, and includes an SRTP
packet that fails authentication, a STUN Binding Request with an
invalid USERNAME or PASSWORD, or any other packet.
5. W3C API Implications These two time intervals might be controlled by the same
configuration item.
Sending consent checks (heartbeats) at a high rate could allow a
malicious application to generate congestion, so applications MUST
NOT be able to send heartbeats faster than 1 per second.
6. DiffServ Treatment for Consent packets
It is RECOMMENDED that STUN consent checks use the same Diffserv
Codepoint markings as the media packets sent on that transport
address. This follows the recommendation of ICE connectivity check
described in section 7.1.2.4 of [RFC5245].
Note: It is possible that different Diffserv Codepoints are used by
different media over the same transport address
[I-D.ietf-tsvwg-rtcweb-qos]. In that case, what should this document
recommend as the Codepoint for STUN consent packets ?
7. W3C API Implications
For the consent freshness and liveness test the W3C specification For the consent freshness and liveness test the W3C specification
should provide APIs as described below: should provide APIs as described below:
1. Ability for the browser to notify the JavaScript that a consent 1. Ability for the browser to notify the JavaScript that a consent
freshness transaction has failed for a media stream and the freshness transaction has failed for a media stream and the
browser has stopped transmitting for that stream. browser has stopped transmitting for that stream.
2. Ability for the JavaScript to start and stop liveness test and 2. Ability for the JavaScript to start and stop liveness test and
set the liveness test interval. set the liveness test interval.
3. Ability for the browser to notify the JavaScript that a liveness 3. Ability for the browser to notify the JavaScript that a liveness
test has failed for a media stream. test has failed for a media stream.
6. Interaction with Keepalives used for Refreshing NAT Bindings 8. Security Considerations
When not actively sending traffic on a nominated candidate pair,
performing consent freshness does not serve any purpose from a
security perspective. If consent freshness is not performed during
this period, the browser continues to performs the ICE keepalives
[RFC5245] or RTP keepalive [RFC6263] to refresh NAT bindings.
7. Security Considerations This document describes a security mechanism.
Security considerations discussed in [RFC5245] are to be taken into The security considerations discussed in [RFC5245] should also be
account. taken into account.
The browser MUST use short-term credential to authenticate the STUN SRTP is encrypted and authenticated with symmetric keys; that is,
messages used for Consent freshness, session liveness and perform both sender and receiver know the keys. With two party sessions,
message integrity check on STUN binding request/response. 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]. Thus, in such shared keying
distributions, receipt of an authenticated SRTP packet is not
sufficient.
8. IANA Considerations 9. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
9. Acknowledgement 10. Acknowledgement
Thanks to Eric Rescorla, Harald Alvestrand, Martin Thomson, Bernard Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus
Aboba, Cullen Jennings and Simon Perreault for their valuable inputs Westerland, Cullen Jennings and Simon Perreault for their valuable
and comments. inputs and comments.
10. Normative References 11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
11.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-02 (work in
progress), February 2014.
[I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and
other packet markings for RTCWeb QoS", draft-ietf-tsvwg-
rtcweb-qos-00 (work in progress), April 2014.
[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.
Authors' Addresses Authors' Addresses
Muthu Arul Mozhi Perumal Muthu Arul Mozhi Perumal
Cisco Systems Cisco Systems
Cessna Business Park Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: mperumal@cisco.com Email: mperumal@cisco.com
skipping to change at page 7, line 4 skipping to change at page 7, line 36
Email: dwing@cisco.com Email: dwing@cisco.com
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Systems Cisco Systems
Cessna Business Park Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: rmohanr@cisco.com Email: rmohanr@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems Cisco Systems
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: tireddy@cisco.com
Martin Thomson
Mozilla
Suite 300
650 Castro Street
Mountain View, California 94041
US
Email: martin.thomson@gmail.com
 End of changes. 43 change blocks. 
125 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/