[rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
Bernard Aboba <bernard.aboba@gmail.com> Wed, 20 May 2015 23:49 UTC
Return-Path: <bernard.aboba@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FD21ACCF3; Wed, 20 May 2015 16:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2SzTX8k85SK; Wed, 20 May 2015 16:48:56 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F571ACCF2; Wed, 20 May 2015 16:48:55 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so171826594wic.0; Wed, 20 May 2015 16:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4DF9tNdhfSl9UzQPWNg8rbnQxHZlo/+LltDTSBBOib4=; b=nPY98dttXluAaKt5JNq80CbqnMaPg9gyp1tkR2rGD0Pezr5Jz4KBuy45/vGEE9hGQG QO6tbdSnrxD0IPC5G8PutZwPQMTiJgNfD+u3lXwPnYSD23llHsnLU97dG4+cW1a4lx1Q VFE4KJpa6FEoZi2WSlS0MpAFYjWqsUZ/ubrQq1ElG9Ur/LlBxkMc+xZOig4C10NFdYck DaEkNefOsBX+s0dmKQGvlih6XKWQb57EuPTC8KAcIfFKx48yiy/vzlRS5BjgODWufx3d hCZJU2dxtKfSgHhj/4Aagh59rk3iNdHe0/U348sgq8omP/6QdKVa2twOUaMM6JteIQoB cW2w==
X-Received: by 10.180.96.196 with SMTP id du4mr8087768wib.77.1432165734417; Wed, 20 May 2015 16:48:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.54.16 with HTTP; Wed, 20 May 2015 16:48:34 -0700 (PDT)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 20 May 2015 16:48:34 -0700
Message-ID: <CAOW+2dsv8CVpaKoBsUvc5MGh2s3xD2J5NiXPAnFUMOhYqSmjzQ@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="f46d043bdabcdc0b2605168c116b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/qlfHaI3quHitTdFCd7GllHXpS50>
Subject: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2015 23:49:00 -0000
This is a review of draft-ietf-rtcweb-stun-consent-freshness. Overall, I believe that this document is not yet ready for publication as a proposed standard, due to transport-related issues. Rather than building upon the RFC 5389 transport model (including the transaction structure and RTT/RTO estimator), the specification proposes a new (and poorly specified) transport model that does not adapt properly to networks with differing transport characteristics. RFC 5389 Section 7.2.1 describes how stun handles retransmissions and RTT/RTO computation: The RTO is an estimate of the round-trip time (RTT), and is computed as described in RFC 2988 [RFC2988], with two exceptions. First, the initial value for RTO SHOULD be configurable (rather than the 3 s recommended in RFC 2988) and SHOULD be greater than 500 ms. The exception cases for this "SHOULD" are when other mechanisms are used to derive congestion thresholds (such as the ones defined in ICE for fixed rate streams), or when STUN is used in non- Internet environments with known network capacities. In fixed-line access links, a value of 500 ms is RECOMMENDED. Second, the value of RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms accuracy SHOULD be maintained. As with TCP, the usage of Karn's algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means that RTT estimates SHOULD NOT be computed from STUN transactions that result in the retransmission of a request. The value for RTO SHOULD be cached by a client after the completion of the transaction, and used as the starting value for RTO for the next transaction to the same server (based on equality of IP address). The value SHOULD be considered stale and discarded after 10 minutes. Retransmissions continue until a response is received, or until a total of Rc requests have been sent. Rc SHOULD be configurable and SHOULD have a default of 7. If, after the last request, a duration equal to Rm times the RTO has passed without a response (providing ample time to get a response if only this final request actually succeeds), the client SHOULD consider the transaction to have failed. Rm SHOULD be configurable and SHOULD have a default of 16. A STUN transaction over UDP is also considered failed if there has been a hard ICMP error [RFC1122]. For example, assuming an RTO of 500 ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response after 39500 ms, the client will consider the transaction to have timed out. The above mechanism addresses a number of issues: 1. Adaptation of the RTO via RTT measurement 2. Consistent number of requests sent without a response (Rc) before transaction failure 3. Total time to transaction failure robust against routing transients Unfortunately, rather than reusing all or part of this approach, the consent freshness specification invents an new and poorly specified transport scheme in Section 4.1: Initial consent to send traffic is obtained using ICE. Consent expires after 30 seconds. That is, if a valid STUN binding response corresponding to any STUN request sent in the last 30 seconds has not been received from the remote peer's transport address, the endpoint MUST cease transmission on that 5-tuple. STUN consent responses received after consent expiry do not re-establish consent, and may be discarded or cause an ICMP error. To prevent expiry of consent, a STUN binding request can be sent periodically. To prevent synchronization of consent checks, each interval MUST be randomized from between 0.8 and 1.2 times the basic period. Implementations SHOULD set a default interval of 5 seconds, resulting in a period between checks of 4 to 6 seconds. Each STUN binding request for consent MUST use a new cryptographically strong [RFC4086] STUN transaction ID. Each STUN binding requests for consent is transmitted once only. Hence, the sender cannot assume that it will receive a response for each consent request, and a response might be for a previous request (rather than for the most recently sent request). Consent expiration causes immediate termination of all outstanding STUN consent transactions. Each STUN transaction is maintained until one of the following criteria is fulfilled: o A STUN response associated with the transaction is received; or o A STUN response associated to a newer transaction is received. The above mechanism has several drawbacks: 1. No RTT/RTO estimation - and given that responses to a request that arrive after a new request is sent are ignored, no ability to make use of the information that is available. Effectively, the specification sets the RTO to be a random value between 4 and 6 seconds, with no relationship to network characteristics. 2. Inconsistent number of requests before failure. Given the randomization, 4 to 6 requests might be sent within the 30 seconds. 3. Unclear timer behavior. Does an implementation continue to send requests until 30 seconds has elapsed, or does it stop before then so as to allow for a response to the last request to arrive? One could interpret the above to imply that requests continue to be sent for up to 30 seconds, but the last request is considered failed as soon as the 30 second timer expires. Detailed comments below. Abstract To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. [BA] This sentence is puzzling, since Section 1 does not mention preventing "excessive traffic" as an objective - focusing instead of prevention of denial of service attacks. AFAICT, the consent freshness mechanism does not actually prevent sending of excessive traffic, nor is it intended to. That is the role of congestion control mechanisms such as those under development in RMCAT, or prior to their deployment, the objective of the "Circuit Breakers" mechanism. As an example, the consent mechanism does not restrict the sending of video on a connection that was only intended for audio, although it would be possible for a peer receiving unwanted media to revoke consent. My suggested rewording is as follows: "To prevent browsers supporting WebRTC from being used to launch denial of service attacks by sending media to unsuspecting victims, periodic consent needs to be obtained from remote endpoints." Section 4.1 An endpoint MUST NOT send data other than paced STUN connectivity checks or responses toward any transport address unless the receiving endpoint consents to receive data. That is, no application data (e.g., RTP or DTLS) can be sent until consent is obtained. After a successful ICE connectivity check on a particular transport address, consent MUST be maintained following the procedure described in this document. [BA] The last sentence seems to imply that consent checks are scheduled before ICE completes, and would therefore interact with the scheduling and pacing mechanism specified in RFC 5245. This does make some sense, since in Trickle ICE, trickling all the candidates might take a while, and media might be sent after a successful response, so that consent would be in order. However, if that is the intent, then it needs to be explicitly stated, and this document needs to contain an Updates: RFC 5245 header. Each STUN binding request for consent MUST use a new cryptographically strong [RFC4086] STUN transaction ID. [BA] I think that RFC 5389 Section 6 says what is in intended here in a more precise way, so it should be referenced instead: As such, the transaction ID MUST be uniformly and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be cryptographically random. After consent is lost for any reason, the same ICE credentials MUST NOT be used on the affected 5-tuple again. That means that a new session, or an ICE restart, is needed to obtain consent to send. [BA] The second sentence does not follow from the first. RFC 5245 enables sending of media once a successful ICE connectivity check has been received. If multiple successful candidate pairs have been identified, why should failure of consent on one candidate pair require an ICE restart if another operational candidate pair exists? Also, it is not clear what "any reason" means - the document only discusses loss of consent due to lack of a response to consent checks. What other reasons are there?
- [rtcweb] Review of draft-ietf-rtcweb-stun-consent… Ted Hardie
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Ram Mohan R (rmohanr)
- [rtcweb] Review of draft-ietf-rtcweb-stun-consent… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Emil Ivov
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Christer Holmberg
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Christer Holmberg
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Emil Ivov
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson