Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

[Martin Thomson <[e-mail]>]

On 20 May 2015 at 16:48, Bernard Aboba <[e-mail]> wrote:
> This is a review of draft-ietf-rtcweb-stun-consent-freshness.
...
> 1. Adaptation of the RTO via RTT measurement

I agree that this is a concern, but we have a means of determining
RTO, so we just need to add text that says something like: The initial
STUN transaction produces a value for RTO on any given candidate pair.
That value is used in determining how long to await a STUN response,
it is updated as new STUN responses are received.

> 2. Consistent number of requests sent without a response (Rc) before
> transaction failure
> 3. Total time to transaction failure robust against routing transients

I don't agree that either of these is a problem.  It's a design,
certainly, but it suffers from a dire lack of determinism in running
time, something that might be exploited to increase denial of service
exposure time.

> 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.

If response i arrives after i+1, that's not going to provide any
useful information about RTO itself (RTO jitter perhaps).  Note that
the original STUN design doesn't even allow you to detect this sort of
reordering, since the transaction ID is reused, so that's strictly
worse.

> 2. Inconsistent number of requests before failure.  Given the randomization,
> 4 to 6 requests might be sent within the 30 seconds.

That doesn't bother me.

> 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.

How can we make this clearer?

It says:

   Consent expires after 30 seconds.

And:

   [...] a STUN binding request can be sent
   periodically [at] a default interval of 5 seconds, [...]

Those are independent.  If you are under the impression that these are
somehow coupled, we can add "This timer is independent of the consent
expiry timeout."

> 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."

I like that.  Note that "excessive traffic" was intended to be in
time, not volume.

> 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.

That's easy, let's just say that this process applies *after* consent
has been acquired.  maybe we could move this up to Section 4:

   Initial consent to send traffic is obtained using ICE.  Consent
   expires after 30 seconds.  An endpoint maintains consent as
described in Section 4.2.

The second sentence can stay where it is to provide context.
Repetition of that point is harmless.

> 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.

WFM.  We can cite that instead.

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

... is needed to obtain consent to send *on that candidate pair*.

There was a long discussion about this point, the conclusion of which
was "use it or lose it".  This captures that conclusion.  I can't
remember the details of the discussion, but I think that it wasn't a
security concern but a robustness one.

> Also, it is not clear what "any reason" means -

We can drop those words.