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

[Martin Thomson <[e-mail]>]

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
>