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

From: Bernard Aboba <[email-masked]>
Date: Mon, 1 Jun 2015 15:06:36 -0700

Comments on the PR:

+pair when the pair enters Succeeded ICE state.  consent; this document
+establishes a 30 second expiry time on consent.

[BA] Is the text starting from "consent;" intended to be there? Looks like
a cut/paste error.

+Consent expires after 30 seconds. That is, if a valid STUN binding
response has
+not been received from the remote peer's transport address in 30 seconds,
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.

[BA] If a response still has not been received, but the RTO timer has not
expired, why should consent be revoked just because the 30 second timer
elapsed? As an example, if a request is sent at 29.9 seconds, and the RTO
timer is 2 seconds, why should consent be revoked only 100 ms after sending
the request?? Also, this text does not appear consistent with the text
below:

+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.  This timer is independent of the consent expiry
timeout.
+</t>
+<t>
+Each STUN binding request for consent MUST use a new STUN transaction
identifier
+for every consent binding request, as described in Section 6 of <xref
+target="RFC5389"/>. Each STUN binding request for consent is transmitted
once
+only. A sender therefore cannot assume
+that it will receive a response for every consent request, and a response
might
+be for a previous request (rather than for the most recently sent request).
+</t>
+<t>
+An endpoint SHOULD await a binding response for each request it sends for
a time
+based on the estimated round-trip time (RTT) (see Section 7.2.1 of <xref
+target="RFC5389"/>) with an allowance for variation in network delay.  The
RTT
+value can be updated as described in <xref target="RFC5389"/>.  After this
time
+elapses, an endpoint can discard associated state and ignore any late
responses.

[BA] I do not understand why responses arriving after the RTO timer expires
are completely ignored.  Post-RTO responses not only indicate that consent
has been maintained, but also that the RTO needs to be revised upwards.  So
I would consider deleting the last sentence.

+All outstanding STUN consent transactions for a candidate pair MUST be
discarded
+when consent expires.

[BA] This part does make sense.  But overall, the paragraph seems to
indicate that consent expires at max(30, Tlast-request + RTO), not 30
seconds.

On Fri, May 22, 2015 at 3:23 PM, Martin Thomson <[email-masked]>
wrote:

> 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:
> > 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?
> >
> > _______________________________________________
> > rtcweb mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Jun 2015 15:50:48 -0700

On 1 June 2015 at 15:06, Bernard Aboba <[email-masked]> wrote:
> [BA] Is the text starting from "consent;" intended to be there? Looks like a
> cut/paste error.

The latter statement was intended to be there.

> the request?? Also, this text does not appear consistent with the text

If you sent something 100ms ago, then it might be useful in the
future, but for now, your consent has expired.  Extending the window
to max(30, Tlast-request + RTO) is extending the window.  It's also
more complicated to implement.

I'm not sure how that would be inconsistent; the text below says that
consent expiry is independent of check interval.

If I were to implement this (as I once did), I would initiate a check
every 5s, awaiting a response for each separately.  If one of those
succeeded, I would update a "lastSuccessfulCheck" variable to the
current time.

Then when sending, I would check that "lastSuccessfulCheck" is more
recent than (now - 30s).  If so, explode.

Or you can run a 30s timer that you reset each time a check succeeds.
Explode if it ever actually runs to completion without being reset.

Neither of those needs to care about RTO.  The implementation of the
checking might (in practice, you can just wait.

> +An endpoint SHOULD await a binding response for each request it sends for a
> time

OK.  Done.

> indicate that consent expires at max(30, Tlast-request + RTO), not 30

I don't know how you get that.  It's certainly isn't the intent.