--- 1/draft-ietf-rtcweb-stun-consent-freshness-00.txt 2014-03-23 20:14:37.357843015 -0700 +++ 2/draft-ietf-rtcweb-stun-consent-freshness-01.txt 2014-03-23 20:14:37.373843410 -0700 @@ -1,20 +1,19 @@ - RTCWEB Muthu. Perumal Internet-Draft D. Wing Intended status: Standards Track R. Ravindranath -Expires: March 24, 2014 T. Reddy +Expires: September 25, 2014 T. Reddy Cisco Systems - September 20, 2013 + March 24, 2014 STUN Usage for Consent Freshness - draft-ietf-rtcweb-stun-consent-freshness-00 + draft-ietf-rtcweb-stun-consent-freshness-01 Abstract Verification of peer consent before sending traffic is necessary in WebRTC deployments to ensure that a malicious JavaScript cannot use 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 @@ -28,41 +27,41 @@ 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 March 24, 2014. + This Internet-Draft will expire on September 25, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 5. W3C API Implications . . . . . . . . . . . . . . . . . . . . 5 6. Interaction with Keepalives used for Refreshing NAT Bindings 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6