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

[Bernard Aboba <[e-mail]>]

Martin said:

"Sure, but I don't think that we *need* that level of sophistication.
There's nothing stopping an implementation from doing smarter things,"

[BA] While ignoring an i response after arrival of i+1 makes sense with
respect to consent, the i RTT value should still be taken into account, so
as to properly estimate the RTO.

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

[BA] If a STUN request is still being tracked (RTO has not yet expired),
would expiration of the 30 second timer still cause consent to expire?  Or
would revocation wait until the RTO timer expires?  The latter makes more
sense to me.

On Fri, May 22, 2015 at 10:28 AM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

> > -----Original Message-----
> > From: Martin Thomson [mailto:[e-mail]]
> > Sent: Friday, May 22, 2015 10:08 PM
> > To: Bernard Aboba; Muthu Arul Mozhi Perumal; Tirumaleswar Reddy
> > (tireddy)
> > Cc: [e-mail]; The IESG; Emil Ivov; Robin Raymond
> > Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
> >
> > 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.
>
>
> https://github.com/Draft-Mafia/IETF-drafts/blob/master/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-13.xml
>
> -Tiru
>
> >
> > 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.
>