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

[Bernard Aboba <[e-mail]>]

Martin said:
> 1. Adaptation of the RTO via RTT measurement

[Martin] 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.

[BA] If you cite the RFC 5389 text relating to initial RTO, caching,
estimation algorithm, etc. you can then use the calculated value to
determine how long to await a STUN response.

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

[BA] The effective transmission rate matters in DDOS more than running time
- which is why the RFC 5389 backoff algorithm makes a difference.  Here an
Rc value of 7 is not as critical as having it be a constant.

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

[BA] That is true if the transaction ID doesn't change (e.g. RFC 5389).
But if the transaction ID changes, then you can use the arrival time of
response i to get a better RTO estimate, even if i+1 arrives first. This is
valuable since it is most likely to happen when the originally calculated
RTO value is too low, making a false retransmission timeout more likely.
RFC 5682 describes some of the concerns relating to F-RTO.

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.

[BA] Right.  So by changing the transaction ID on each request, it is
possible to do better - particularly if F-RTO can be taken into account.

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

[BA] Varying Rc will produce a false retransmission probability that will
vary by network conditions, particularly if Rc can be small (e.g. only a
few retransmissions prior to declaring consent revocation).

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

[BA] If consent expires at 30 seconds + RTO (or better, at last request
sending time plus RTO) then that would clarify things.

It says:

   Consent expires after 30 seconds.

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

[BA] Why would time matter if consent packets aren't being sent (e.g.
backoff)?

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

[BA] The question is when consent is acquired. I'd assume that this begins
when media starts being sent - which according to RFC 5245 can occur after
a successful connectivity check response.  So ICE isn't necessarily
complete.

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

[BA] That part makes sense - but if there is another valid pair, it should
be possible to start sending media on that pair without having to do an ICE
restart.  That is allowed under RFC 5245.


On Thu, May 21, 2015 at 4:10 PM, Martin Thomson <[e-mail]>
wrote:

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