--- 1/draft-ietf-rtcweb-stun-consent-freshness-06.txt 2014-09-15 16:14:35.599145636 -0700 +++ 2/draft-ietf-rtcweb-stun-consent-freshness-07.txt 2014-09-15 16:14:35.619146127 -0700 @@ -1,49 +1,49 @@ RTCWEB M. Perumal Internet-Draft Ericsson Intended status: Standards Track D. Wing -Expires: February 13, 2015 R. Ravindranath +Expires: March 19, 2015 R. Ravindranath T. Reddy Cisco Systems M. Thomson Mozilla - August 12, 2014 + September 15, 2014 STUN Usage for Consent Freshness - draft-ietf-rtcweb-stun-consent-freshness-06 + draft-ietf-rtcweb-stun-consent-freshness-07 Abstract To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. - This document describes a consent mechanism using a new STUN usage. - This same mechanism can also determine connection loss ("liveness") - with a remote peer. + This document describes a consent mechanism using a new Session + Traversal Utilities for NAT (STUN) usage. This same mechanism can + also determine connection loss ("liveness") with a remote peer. 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 February 13, 2015. + This Internet-Draft will expire on March 19, 2015. Copyright Notice Copyright (c) 2014 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 @@ -69,45 +69,43 @@ 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction To prevent attacks on peers, RTP endpoints have to ensure the remote peer wants to receive traffic. This is performed both when the - session is first established to the remote peer using ICE - connectivity checks, and periodically for the duration of the session - using the procedures defined in this document. + session is first established to the remote peer using Interactive + Connectivity Establishment ICE [RFC5245] connectivity checks, and + periodically for the duration of the session using the procedures + defined in this document. - When a session is first established, WebRTC implementations are - required to perform STUN connectivity checks as part of ICE - [RFC5245]. That initial consent is not described further in this - document and it is assumed that ICE is being used for that initial - consent. + When a session is first established, ICE implementations obtain + initial consent by performing STUN connectivity checks as part of + ICE. That initial consent is not described further in this document + and it is assumed that ICE is being used for that initial consent. Related to consent is loss of connectivity ("liveness"). Many applications want notification of connection loss to take appropriate actions (e.g., alert the user, try switching to a different interface). This document describes a new STUN usage with exchange of request and response messages to verify the remote peer's consent to receive traffic, and the absence of which for a period of time indicates a 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. + When a (full) ICE implementation interworks with an ICE-lite + implementation the ICE-lite implementation will not generate consent + checks, but will just just respond to consent checks it receives. 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]. Consent: It is the mechanism of obtaining permission to send traffic to a certain transport address. This is the initial consent to send traffic, which is obtained by ICE or a TCP handshake. @@ -124,34 +122,35 @@ port number. 3. Design Considerations Although ICE requires periodic keepalive traffic to keep NAT bindings alive (Section 10 of [RFC5245], [RFC6263]), those keepalives are sent as STUN Indications which are send-and-forget, and do not evoke a response. A response is necessary both for consent to continue sending traffic, as well as to verify session liveness. Thus, we 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]. + used for that mechanism because ICE implementations are already + required to continue listening for ICE messages, as described in + section 10 of [RFC5245]. 4. Solution There are two ways consent to send traffic is revoked: expiration of consent and immediate revocation of consent, which are discussed in the following sections. 4.1. Expiration of Consent - A WebRTC browser performs a combined consent freshness and session - liveness test using STUN request/response as described below: + A WebRTC implementation [I-D.ietf-rtcweb-overview], which implements + ICE, MUST perform a combined consent freshness and session liveness + test using STUN request/response as described below: An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) 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. During ICE restart consent checks MUST continue to be sent on previously validated pair, and MUST be responded to on the previously validated pair, until ICE @@ -185,24 +184,24 @@ endpoint MUST cease transmission on that 5-tuple. To meet the security needs of consent, an untrusted application (e.g., JavaScript) MUST NOT be able to obtain or control the STUN transaction ID, because that enables spoofing STUN responses, falsifying consent. While TCP affords some protection from off-path attackers ([RFC5961], [RFC4953]), there is still a risk an attacker could cause a TCP sender to send packets forever by spoofing ACKs. To prevent such an - attack, consent checks MUST be performed over all WebRTC-initiated - transport connections, including TCP. In this way, an off-path - attacker spoofing TCP segments can not cause a TCP sender to send - packets longer than the consent timer (30 seconds). + attack, consent checks MUST be performed over all transport + connections, including TCP. In this way, an off-path attacker + spoofing TCP segments can not cause a TCP sender to send packets + longer than the consent timer (30 seconds). An endpoint that is not sending any application traffic does not need to obtain consent which can slightly conserve its resources. However, the endpoint needs to ensure its NAT or firewall mappings persist which can be done using keepalive or other techniques (see Section 10 of [RFC5245] and see [RFC6263]). If the endpoint wants to send application traffic, it needs to first obtain consent if its consent has expired. 4.2. Immediate Revocation of Consent @@ -323,23 +322,24 @@ Keeping Alive the NAT Mappings Associated with RTP / RTP 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-rtcweb-transports] - Alvestrand, H., "Transports for RTCWEB", draft-ietf- - rtcweb-transports-05 (work in progress), June 2014. + [I-D.ietf-rtcweb-overview] + Alvestrand, H., "Overview: Real Time Protocols for + Browser-based Applications", draft-ietf-rtcweb-overview-11 + (work in progress), August 2014. [I-D.ietf-tsvwg-rtcweb-qos] Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Polk, "DSCP and other packet markings for RTCWeb QoS", draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June 2014. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. @@ -356,22 +356,23 @@ 2010. [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010. Authors' Addresses Muthu Arul Mozhi Perumal Ericsson - Mahadevapura - Bangalore, Karnataka 560048 + Ferns Icon + Doddanekundi, Mahadevapura + Bangalore, Karnataka 560037 India Email: muthu.arul@gmail.com Dan Wing Cisco Systems 821 Alder Drive Milpitas, California 95035 USA