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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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