Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00

[Martin Thomson <[e-mail]>]

These are good observations.

On 26 November 2013 02:34, Tirumaleswar Reddy (tireddy)
<[e-mail]> wrote:
> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.

Yes, that would be the plan.  We would also have to force the
inclusion of peer_allowed_to_send(1) in the extension, lest things get
perverse.

> [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Generating arbitrary content (payload and padding 40 bytes), encrypting it). Though this may not a concern since heartbeat will only be sent when authenticated packets are not received.

I'm thinking: a) not a concern because it's only a factor if you
aren't sending, and b) not a concern because it's not a lot of work to
generate an authenticated packet.  Less work I think if you are using
AES-GCM modes.

> [4] DTLS heartbeat doubles the timer value at each retransmission but with STUN consent retransmission is repeated every 500ms. There seems to be no application level control on the retransmission mechanism used by OpenSSL DTLS implementation.

That's a good point, I'll have to check to see if we need to update
6520, or whether just saying to avoid retransmission is sufficient.
(I think the latter, but don't care too much.)

> [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS heartbeat API.

This is true to exactly the same extent for both forms.  Some STUN
implementations don't allow for the sending of a single check, they
also do the full exponential backoff thing.