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

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 May 2015 16:48:34 -0700

This is a review of draft-ietf-rtcweb-stun-consent-freshness.

Overall, I believe that this document is not yet ready for publication as a
proposed standard,
due to transport-related issues.  Rather than building upon the RFC 5389
transport model
(including the transaction structure and RTT/RTO estimator), the
specification proposes a
new (and poorly specified) transport model that does not adapt properly
to networks with differing transport characteristics.

RFC 5389 Section 7.2.1 describes how stun handles retransmissions and
RTT/RTO computation:

   The RTO is an estimate of the round-trip time (RTT),
   and is computed as described in RFC 2988 [RFC2988], with two
   exceptions.  First, the initial value for RTO SHOULD be configurable
   (rather than the 3 s recommended in RFC 2988) and SHOULD be greater
   than 500 ms.  The exception cases for this "SHOULD" are when other
   mechanisms are used to derive congestion thresholds (such as the ones
   defined in ICE for fixed rate streams), or when STUN is used in non-
   Internet environments with known network capacities.  In fixed-line
   access links, a value of 500 ms is RECOMMENDED.  Second, the value of
   RTO SHOULD NOT be rounded up to the nearest second.  Rather, a 1 ms
   accuracy SHOULD be maintained.  As with TCP, the usage of Karn's
   algorithm is RECOMMENDED [KARN87].  When applied to STUN, it means
   that RTT estimates SHOULD NOT be computed from STUN transactions that
   result in the retransmission of a request.

   The value for RTO SHOULD be cached by a client after the completion
   of the transaction, and used as the starting value for RTO for the
   next transaction to the same server (based on equality of IP
   address).  The value SHOULD be considered stale and discarded after
   10 minutes.

   Retransmissions continue until a response is received, or until a
   total of Rc requests have been sent.  Rc SHOULD be configurable and
   SHOULD have a default of 7.  If, after the last request, a duration
   equal to Rm times the RTO has passed without a response (providing
   ample time to get a response if only this final request actually
   succeeds), the client SHOULD consider the transaction to have failed.
   Rm SHOULD be configurable and SHOULD have a default of 16.  A STUN
   transaction over UDP is also considered failed if there has been a
   hard ICMP error [RFC1122].  For example, assuming an RTO of 500 ms,
   requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500
   ms, 15500 ms, and 31500 ms.  If the client has not received a
   response after 39500 ms, the client will consider the transaction to
   have timed out.

The above mechanism addresses a number of issues:

1. Adaptation of the RTO via RTT measurement
2. Consistent number of requests sent without a response (Rc) before
transaction failure
3. Total time to transaction failure robust against routing transients

Unfortunately, rather than reusing all or part of this approach, the
consent freshness specification invents an new and poorly specified
transport scheme in Section 4.1:

   Initial consent to send traffic is obtained using ICE.  Consent
   expires after 30 seconds.  That is, if a valid STUN binding response
   corresponding to any STUN request sent in the last 30 seconds has not
   been received from the remote peer's transport address, the endpoint
   MUST cease transmission on that 5-tuple.  STUN consent responses
   received after consent expiry do not re-establish consent, and may be
   discarded or cause an ICMP error.

   To prevent expiry of consent, a STUN binding request can be sent
   periodically.  To prevent synchronization of consent checks, each
   interval MUST be randomized from between 0.8 and 1.2 times the basic
   period.  Implementations SHOULD set a default interval of 5 seconds,
   resulting in a period between checks of 4 to 6 seconds.

   Each STUN binding request for consent MUST use a new
   cryptographically strong [RFC4086] STUN transaction ID.  Each STUN
   binding requests for consent is transmitted once only.  Hence, the
   sender cannot assume that it will receive a response for each consent
   request, and a response might be for a previous request (rather than
   for the most recently sent request).  Consent expiration causes
   immediate termination of all outstanding STUN consent transactions.
   Each STUN transaction is maintained until one of the following
   criteria is fulfilled:

   o  A STUN response associated with the transaction is received; or

   o  A STUN response associated to a newer transaction is received.

The above mechanism has several drawbacks:

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.

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

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.

Detailed comments below.

Abstract

To prevent sending excessive traffic to an endpoint, periodic consent needs
to be obtained from that remote endpoint.

[BA] This sentence is puzzling, since Section 1 does not mention preventing
"excessive traffic" as an objective -  focusing instead of prevention of
denial of service attacks.

AFAICT, the consent freshness mechanism does not actually prevent sending
of excessive traffic, nor is it  intended to. That is the role of
congestion control mechanisms such as those under development in RMCAT, or
prior to their deployment, the objective of the "Circuit Breakers"
mechanism.

As an example,  the consent mechanism does not restrict the sending of
video on a connection that was only  intended for audio, although it would
be possible for a peer receiving unwanted media to revoke consent.

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

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.

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.

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?

Also, it is not clear what "any reason" means - the document only discusses
loss of consent due to lack of a response to consent checks.  What other
reasons are there?

---

From: Emil Ivov <[email-masked]>
Date: Thu, 21 May 2015 22:01:21 +0200

On 21.05.15 1:48, Bernard Aboba wrote:
> Overall, I believe that this document is not yet ready for publication
> as a proposed standard,

I think we can easily fix this if we replace semantic usage of "STUN 
request" throughout the specification with "STUN transaction".

For example, in page 4 in the following paragraph:

    for the most recently sent request).

replacing request with transaction we would get:

    Each STUN transaction MUST use a new cryptographically strong
    [RFC4086] STUN transaction ID.  Each STUN transaction for consent
    is transmitted once only. Hence, the sender cannot assume that it
    will receive a response for each consent transaction, and a response
    might be for a previous transaction (rather than for the most
    recently sent request).

The fact that this entire paragraphs becomes redundant after the change 
is probably good indication that we were basically defining STUN 
transactions ...

Obviously using transactions for every consent check would leave us with 
a couple of potential issues, like, what if you already have an ongoing 
STUN transaction and randomization tells you to start a new one. Those 
could be easily fixed however. For example, by simply starting the 
random timer after a STUN transaction has completed (as opposed to after 
sending the request).

Emil

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 May 2015 14:13:08 -0700

Emil said:

   "Each STUN transaction MUST use a new cryptographically strong

[BA] Within a STUN transaction you can have retransmissions, so not sure
about the "transmitted once only" part.  But I generally agree with your
point - reusing the RF 5389 STUN transaction and RTT/RTO mechanism would
fix the problems.

 The fact that this entire paragraphs becomes redundant after the change is
probably good indication that we were basically defining STUN transactions
...

[BA] I agree - and the mechanism specified in this document is not as good
as the one in RFC 5389 (which is already widely deployed).

 Obviously using transactions for every consent check would leave us with a
couple of potential issues, like, what if you already have an ongoing STUN
transaction and randomization tells you to start a new one. Those could be
easily fixed however. For example, by simply starting the random timer
after a STUN transaction has completed (as opposed to after sending the
request)."

[BA] Exactly.  So you end up with a series of STUN transactions spaced
randomly apart.  Except now you get adaptation to network characteristics,
backoff (which reduces the ability to use freshness to mount denial of
service attacks), RTT/RTO estimation, etc.  Plus you get to reuse RFC 5389
code (which many of us were going to do anyway, since it will work better
than what is specified in this draft).

On Thu, May 21, 2015 at 1:01 PM, Emil Ivov <[email-masked]> wrote:

> The fact that this entire paragraphs becomes redundant after the change is
> probably good indication that we were basically defining STUN transactions
> ...
>
> Obviously using transactions for every consent check would leave us with a
> couple of potential issues, like, what if you already have an ongoing STUN
> transaction and randomization tells you to start a new one. Those could be
> easily fixed however. For example, by simply starting the random timer
> after a STUN transaction has completed (as opposed to after sending the
> request).
>
> Emil
>
> --
> https://jitsi.org
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2015 16:10:19 -0700

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

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

> needs to be obtained from remote endpoints."

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

> 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

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.

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

WFM.  We can cite that instead.

> used on the affected 5-tuple again. That means that a new session, or an ICE
> restart, is needed to obtain consent to send.
>
> 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.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 May 2015 16:54:52 -0700

> 1. Adaptation of the RTO via RTT measurement

[Martin] I agree that this is a concern, but we have a means of determining

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

[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

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

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

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

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

It says:

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

> pacing mechanism specified in RFC 5245.  This does make some sense, since
in

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

[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 <[email-masked]>
wrote:

> arrive
> randomization,
> requests
> more
> ICE
> received.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 May 2015 02:40:48 +0000

Hi Emil,

The current mechanism helps determine RTT and packet loss, since transaction could be confused with the retransmission mechanism in RFC 5389 it was not used. 

-Tiru

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Emil Ivov
> Sent: Friday, May 22, 2015 1:31 AM
> To: Bernard Aboba; [email-masked]; The IESG
> Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 May 2015 03:55:06 +0000

Hi,

...

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

A while ago, we agreed that consent does not need to be maintained on candidate pairs that aren't currently used. That should not be seen as lost consent (i.e. if the UA wants to start sending data on the candidate pair it should not have to do ICE restart or create a  new session).

So, consent is lost if the UA sends consent requests, and does not receive a response. Consent is NOT lost if the UA stops sending consent requests (and therefor obviously will not receive a response).

Perhaps that is clear in the draft, but if people have a different understanding it may need to be clarified :)

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 May 2015 21:53:47 -0700

Christer said:

"A while ago, we agreed that consent does not need to be maintained on
candidate pairs that aren't currently used."

[BA] If the specification were to say that consent is required once media
is sent, then this would logically follow.

That should not be seen as lost consent (i.e. if the UA wants to start
sending data on the candidate pair it should not have to do ICE restart or
create a  new session).

[BA] I agree. As long as it can obtain consent on the new pair (without
having to update the ufrag/pwd), it should be fine.

So, consent is lost if the UA sends consent requests, and does not receive
a response.

[BA] Consent is lost for that candidate pair, and that pair alone.  If
connectivity checks are being done on an unused candidate pair (as
advocated in Justin's nombis draft), the consent mechanism does not apply
until media is sent on that pair.  So you can't revoke consent on a
candidate pair if media isn't being sent on the pair.

Perhaps that is clear in the draft, but if people have a different
understanding it may need to be clarified :)

[BA] I agree with your perspective, but I do think it could be made more
clear in the document.

On Thu, May 21, 2015 at 8:55 PM, Christer Holmberg <
[email-masked]> wrote:

> >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.
>
> A while ago, we agreed that consent does not need to be maintained on
> candidate pairs that aren't currently used. That should not be seen as lost
> consent (i.e. if the UA wants to start sending data on the candidate pair
> it should not have to do ICE restart or create a  new session).
>
> So, consent is lost if the UA sends consent requests, and does not receive
> a response. Consent is NOT lost if the UA stops sending consent requests
> (and therefor obviously will not receive a response).
>
> Perhaps that is clear in the draft, but if people have a different
> understanding it may need to be clarified :)
>
> Regards,
>
> Christer
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 May 2015 05:48:57 +0000

It is discussed in section 4 of the draft
<snip>
   An endpoint that is not sending any application data does not need to
   maintain consent.  However, not sending any traffic could cause NAT
   or firewall mappings to expire.  Furthermore, having one peer unable
   to send is detrimental to many protocols.  Absent better information
   about the network, if an endpoint needs to ensure its NAT or firewall
   mappings do not expire, it can be done using keepalive or other
   techniques (see Section 10 of [RFC5245]<http://tools.ietf.org/html/rfc5245#section-10> and see [RFC6263<http://tools.ietf.org/html/rfc6263>]).
</snip>

-Tiru

From: rtcweb [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, May 22, 2015 10:24 AM
To: Christer Holmberg
Cc: [email-masked]; The IESG
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

Christer said:

"A while ago, we agreed that consent does not need to be maintained on candidate pairs that aren't currently used."

[BA] If the specification were to say that consent is required once media is sent, then this would logically follow.

That should not be seen as lost consent (i.e. if the UA wants to start sending data on the candidate pair it should not have to do ICE restart or create a  new session).

[BA] I agree. As long as it can obtain consent on the new pair (without having to update the ufrag/pwd), it should be fine.

So, consent is lost if the UA sends consent requests, and does not receive a response.

[BA] Consent is lost for that candidate pair, and that pair alone.  If connectivity checks are being done on an unused candidate pair (as advocated in Justin's nombis draft), the consent mechanism does not apply until media is sent on that pair.  So you can't revoke consent on a candidate pair if media isn't being sent on the pair.

[BA] I agree with your perspective, but I do think it could be made more clear in the document.

On Thu, May 21, 2015 at 8:55 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 May 2015 08:47:16 +0000

Hi,

>[BA] If the specification were to say that consent is required once media is sent, then this would logically follow.

Or, WHILE media is sent :) Because, if you stop sending media on a pair (e.g. because you switch to another pair), you can also stop doing consent, but that doesn’t mean consent will be lost.

>>That should not be seen as lost consent (i.e. if the UA wants to start sending data on the candidate pair it should not have to do ICE >>restart or create a  new session).
>

It could even be an old pair, on which the UA previously sent media, but then switched to another pair (for whatever reason).

>[BA] Consent is lost for that candidate pair, and that pair alone.

Correct.

>If connectivity checks are being done on an unused candidate pair (as advocated in Justin's nombis draft), the
>consent mechanism does not apply until media is sent on that pair.  So you can't revoke consent on a candidate
>pair if media isn't being sent on the pair.

Correct.

Of course, if you want to maintain the pair, you still have to send keep-alives, but that’s a separate story :)

Regards,

Christer

...

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 09:38:06 -0700

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.

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

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

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

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

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

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

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

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

> restart.  That is allowed under RFC 5245.

Correct.  We can add that clarification too.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 May 2015 17:28:51 +0000

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Friday, May 22, 2015 10:08 PM
> To: Bernard Aboba; Muthu Arul Mozhi Perumal; Tirumaleswar Reddy
> (tireddy)
> Cc: [email-masked]; The IESG; Emil Ivov; Robin Raymond
> 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

> > [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's reasonable.  I'll propose text as soon as I can lay my hands on a copy of
> a draft.
> 
> >> transaction failure 3. Total time to transaction failure robust
> >> against routing transients
> >
> > - 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.
> 
> consent is active.  ICE sends at 20ms intervals.  Open loop.  That matters far
> more for DDOS.
> 
> >> 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.
> >
> > [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.
> 
> 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).
> 
> >> 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.
> >
> > [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.
> 
> 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.
> 
> 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.)
> 
> > [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.
> 
> > [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.
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 May 2015 10:40:55 -0700

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) <
[email-masked]> wrote:

> requires a

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 10:54:37 -0700

> would revocation wait until the RTO timer expires?  The latter makes more

I think the former is better since it makes the consent window more
deterministic.  The only consequence there is that an increase in RTO
over the course of that 30s interval will increase the probability of
failure.

If we assume that a client sends every 5s, it should be receiving at
5s intervals too.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 22 May 2015 23:31:09 +0200

Hey Martin,

Taking a step back, could you maybe remind us exactly why we are defining
this new sort of a 30 second transaction instead of just using
traditional STUN transactions every time our periodic timer fires?

I wasn't able to find this here and there's no rationale in the draft. Was
it maybe decided at a meeting at some point?

Emil

On Friday, May 22, 2015, Martin Thomson <[email-masked]> wrote:

> On 22 May 2015 at 10:40, Bernard Aboba <[email-masked]
> <javascript:;>> wrote:

-- 
sent from my mobile

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 14:35:38 -0700

On 22 May 2015 at 14:31, Emil Ivov <[email-masked]> wrote:
> this new sort of a 30 second transaction instead of just using traditional
> STUN transactions every time our periodic timer fires?

Transactions take too long, they send too many checks, and those
checks appear too close together, meaning that they are prone to loss
due to routing transients.

I think that's it.  There's probably more.

> it maybe decided at a meeting at some point?

It was, or maybe on list.  It's been like this since almost the second
or third revision.

It's not that common to provide extensive rationale in specifications like this.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 15:23:49 -0700

To reset the thread, here are the changes that I am going to propose:

https://github.com/martinthomson/IETF-drafts-1/compare/vc...martinthomson:bernard-consent

I have a pull request on the repo that you can follow, but the diff
there is a complete mess due to some nasty version control issues:

https://github.com/Draft-Mafia/IETF-drafts/pull/10

The following changes are substantive in some sense:

Consent is maintained now by receiving a valid response. Previously,
it was receiving a response to one of the checks that were initiated
in the 30s window (which would have prevented this from working with
RTT approaching 30s, so I considered it harmless). This change should
make it more robust.

Requests are abandoned when RTT (+delta) expires or when consent is
lost. Requests aren't abandoned by receiving a response to a later
request (the unlikely out of order request Bernard was concerned
with). This means that there is another timer that runs, in theory
(clever implementers will learn that this timer doesn't need to be an
actual timer).

On 20 May 2015 at 16:48, Bernard Aboba <[email-masked]> wrote:
> Unfortunately, rather than reusing all or part of this approach, the consent
> freshness specification invents an new and poorly specified transport scheme
> in Section 4.1:
>
> AFAICT, the consent freshness mechanism does not actually prevent sending of
> excessive traffic, nor is it  intended to. That is the role of congestion
> control mechanisms such as those under development in RMCAT, or prior to
> their deployment, the objective of the "Circuit Breakers" mechanism.
>
> As an example,  the consent mechanism does not restrict the sending of video
> on a connection that was only  intended for audio, although it would be
> possible for a peer receiving unwanted media to revoke consent.
>