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

[Bernard Aboba <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>