draft-ietf-rtcweb-stun-consent-freshness-04.txt   draft-ietf-rtcweb-stun-consent-freshness-05.txt 
RTCWEB M. Perumal RTCWEB M. Perumal
Internet-Draft D. Wing Internet-Draft Ericsson
Intended status: Standards Track R. Ravindranath Intended status: Standards Track D. Wing
Expires: December 19, 2014 T. Reddy Expires: January 5, 2015 R. Ravindranath
T. Reddy
Cisco Systems Cisco Systems
M. Thomson M. Thomson
Mozilla Mozilla
June 17, 2014 July 4, 2014
STUN Usage for Consent Freshness STUN Usage for Consent Freshness
draft-ietf-rtcweb-stun-consent-freshness-04 draft-ietf-rtcweb-stun-consent-freshness-05
Abstract Abstract
To prevent sending excessive traffic to an endpoint, periodic consent To prevent sending excessive traffic to an endpoint, periodic consent
needs to be obtained from that remote endpoint. needs to be obtained from that remote endpoint.
This document describes a consent mechanism using a new STUN usage. This document describes a consent mechanism using a new STUN usage.
This same mechanism can also determine connection loss ("liveness") This same mechanism can also determine connection loss ("liveness")
with a remote peer. with a remote peer.
skipping to change at page 1, line 39 skipping to change at page 1, line 40
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 December 19, 2014. This Internet-Draft will expire on January 5, 2015.
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 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Expiration of Consent . . . . . . . . . . . . . . . . . . 3 4.1. Expiration of Consent . . . . . . . . . . . . . . . . . . 4
4.2. Immediate Revocation of Consent . . . . . . . . . . . . . 5 4.2. Immediate Revocation of Consent . . . . . . . . . . . . . 5
5. Connection Liveness . . . . . . . . . . . . . . . . . . . . . 5 5. Connection Liveness . . . . . . . . . . . . . . . . . . . . . 5
6. DiffServ Treatment for Consent packets . . . . . . . . . . . 5 6. DiffServ Treatment for Consent packets . . . . . . . . . . . 6
7. W3C API Implications . . . . . . . . . . . . . . . . . . . . 6 7. W3C API Implications . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
To prevent attacks on peers, RTP endpoints have to ensure the remote To prevent attacks on peers, RTP endpoints have to ensure the remote
peer wants to receive traffic. This is performed both when the peer wants to receive traffic. This is performed both when the
session is first established to the remote peer using ICE session is first established to the remote peer using ICE
skipping to change at page 3, line 5 skipping to change at page 3, line 7
Related to consent is loss of connectivity ("liveness"). Many Related to consent is loss of connectivity ("liveness"). Many
applications want notification of connection loss to take appropriate applications want notification of connection loss to take appropriate
actions (e.g., alert the user, try switching to a different actions (e.g., alert the user, try switching to a different
interface). interface).
This document describes a new STUN usage with exchange of request and This document describes a new STUN usage with exchange of request and
response messages to verify the remote peer's consent to receive response messages to verify the remote peer's consent to receive
traffic, and the absence of which for a period of time indicates a traffic, and the absence of which for a period of time indicates a
loss of liveness. loss of liveness.
WebRTC endpoints are required to support full ICE as specified in
section 3.4 of [I-D.ietf-rtcweb-transports]. However, when WebRTC
endpoints interwork with other endpoints that support only ICE-lite
(e.g. gateways) those endpoints will not generate consent checks, but
just respond to consent checks they receive.
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 to send traffic Consent: It is the mechanism of obtaining permission to send traffic
to a certain transport address. This is the initial consent to to a certain transport address. This is the initial consent to
send traffic, which is obtained by ICE or a TCP handshake. send traffic, which is obtained by ICE or a TCP handshake.
skipping to change at page 4, line 10 skipping to change at page 4, line 20
An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP,
DTLS) on an ICE-initiated connection unless the receiving endpoint DTLS) on an ICE-initiated connection unless the receiving endpoint
consents to receive the data. After a successful ICE connectivity consents to receive the data. After a successful ICE connectivity
check on a particular transport address, subsequent consent MUST be check on a particular transport address, subsequent consent MUST be
obtained following the procedure described in this document. The obtained following the procedure described in this document. The
consent expires after a fixed amount of time. consent expires after a fixed amount of time.
Explicit consent to send is obtained by sending an ICE binding Explicit consent to send is obtained by sending an ICE binding
request to the remote peer's Transport Address and receiving a request to the remote peer's Transport Address and receiving a
matching, authenticated, non-error ICE binding response from the matching, authenticated, non-error ICE binding response from the
inverted remote peer's Transport Address. These ICE binding requests remote peer's Transport Address. These ICE binding requests and
and responses are authenticated using the same short-term credentials responses are authenticated using the same short-term credentials as
as the initial ICE exchange. Implementations MUST cease sending data the initial ICE exchange. Implementations MUST cease sending data if
if their consent expires. To prevent expiry of consent, a STUN their consent expires. To prevent expiry of consent, a STUN binding
binding request is sent every N milliseconds, where N SHOULD be 5000 request is sent every N milliseconds, where N SHOULD be 5000
milliseconds and MUST be randomized at least 20% above and 20% below milliseconds and MUST be randomized at least 20% above and 20% below
that value (to prevent prevent network synchronization). Using the that value (to prevent prevent network synchronization). Using the
value 5000 milliseconds and that 20% randomization range, N would be value 5000 milliseconds and that 20% randomization range, N would be
a value between 4000 and 6000. These STUN binding requests for a value between 4000 and 6000. These STUN binding requests for
consent are not re-transmitted. Each STUN binding request for consent are not re-transmitted. Each STUN binding request for
consent re-calculates a new random value N and a new consent re-calculates a new random value N and a new
cryptographically-random [RFC4086] STUN transaction ID. cryptographically-random [RFC4086] STUN transaction ID.
The initial Consent to send traffic is obtained by ICE. Consent The initial Consent to send traffic is obtained by ICE. Consent
expires after 30 seconds. That is, if a valid STUN binding response expires after 30 seconds. That is, if a valid STUN binding response
corresponding to one of the STUN requests sent in the last 30 seconds corresponding to one of the STUN requests sent in the last 30 seconds
has not been received from the inverted 5-tuple, the endpoint MUST has not been received from the remote peer's Transport Address, the
cease transmission on that 5-tuple. endpoint MUST cease transmission on that 5-tuple.
To meet the security needs of consent, an untrusted application To meet the security needs of consent, an untrusted application
(e.g., JavaScript) MUST NOT be able to obtain or control the STUN (e.g., JavaScript) MUST NOT be able to obtain or control the STUN
transaction ID, because that enables spoofing STUN responses, transaction ID, because that enables spoofing STUN responses,
falsifying consent. falsifying consent.
While TCP affords some protection from off-path attackers ([RFC5961], While TCP affords some protection from off-path attackers ([RFC5961],
[RFC4953]), there is still a risk an attacker could cause a TCP [RFC4953]), there is still a risk an attacker could cause a TCP
sender to send packets forever by spoofing ACKs. To prevent such an sender to send packets forever by spoofing ACKs. To prevent such an
attack, consent checks MUST be performed over all WebRTC-initiated attack, consent checks MUST be performed over all WebRTC-initiated
skipping to change at page 7, line 31 skipping to change at page 7, line 41
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 11.2. Informative References
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D. and D. Wing, "Encrypted Key Transport for McGrew, D. and D. Wing, "Encrypted Key Transport for
Secure RTP", draft-ietf-avtcore-srtp-ekt-02 (work in Secure RTP", draft-ietf-avtcore-srtp-ekt-02 (work in
progress), February 2014. progress), February 2014.
[I-D.ietf-rtcweb-transports]
Alvestrand, H., "Transports for RTCWEB", draft-ietf-
rtcweb-transports-05 (work in progress), June 2014.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
other packet markings for RTCWeb QoS", draft-ietf-tsvwg- Polk, "DSCP and other packet markings for RTCWeb QoS",
rtcweb-qos-00 (work in progress), April 2014. draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June
2014.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
4953, July 2007. 4953, July 2007.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, August Robustness to Blind In-Window Attacks", RFC 5961, August
2010. 2010.
Authors' Addresses Authors' Addresses
Muthu Arul Mozhi Perumal Muthu Arul Mozhi Perumal
Cisco Systems Ericsson
Cessna Business Park Mahadevapura
Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560048
Bangalore, Karnataka 560103
India India
Email: mperumal@cisco.com Email: muthu.arul@gmail.com
Dan Wing Dan Wing
Cisco Systems Cisco Systems
821 Alder Drive 821 Alder Drive
Milpitas, California 95035 Milpitas, California 95035
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Ram Mohan Ravindranath Ram Mohan Ravindranath
 End of changes. 14 change blocks. 
25 lines changed or deleted 36 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/