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

[Bernard Aboba <[e-mail]>]

Emil said:

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

[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 <[e-mail]> wrote:

> On 21.05.15 1:48, Bernard Aboba wrote:
>
>> 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.
>>
>
> 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:
>
>    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).
>
> 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
>