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

[Martin Thomson <[e-mail]>]

Tiru/Muthu, where the hell is the master copy of the draft?  This
requires a little care and I'd like to propose several pull requests.

On 21 May 2015 at 16:54, Bernard Aboba <[e-mail]> wrote:
> 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.

That's reasonable.  I'll propose text as soon as I can lay my hands on
a copy of a draft.

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

The draft requires at most one check every 4s for a pair and only when
consent is active.  ICE sends at 20ms intervals.  Open loop.  That
matters far more for DDOS.

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

Sure, but I don't think that we *need* that level of sophistication.
There's nothing stopping an implementation from doing smarter things,
but we are only looking to ensure that consent doesn't persist
indefinitely.

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

See above regarding unnecessary sophistication.

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

I can see where you are coming from here.  I think that we need a
different fix, if anything.

1. STUN requests are sent at a regular interval (with variance).
2. Each STUN request is tracked for RTO+delta.
3. If a successful STUN response has been received in the last 30
seconds, you have consent.

That is a subtle change, but it would allow for connections with an
RTO greater than 30 seconds.  The only actual problem I can detect
with the current formulation.

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

Let me rephrase.  The mechanism in this draft prevents packets from
being sent to an unwilling recipient.  It does that by limiting the
*time* that this can happen.  It does nothing about the *volume*,
either in number of packets or number of bytes.  I agree that
"excessive" implies the latter (and hence think that your proposed
text in this regard was good.)

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

Right.  We can clarify that too.  If only I had a copy of the damned
draft, I'd propose some changes.

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

Correct.  We can add that clarification too.