[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?