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

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

|-----Original Message-----
|From: Martin Thomson [mailto:[e-mail]]
|Sent: Wednesday, November 27, 2013 10:54 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Tirumaleswar Reddy (tireddy); [e-mail];
|[e-mail]
|Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
|
|On 26 November 2013 18:06, Muthu Arul Mozhi Perumal (mperumal)
|<[e-mail]> wrote:
|> Are there cases where you won't do ICE but do DTLS, for WebRTC? If not, I think you can combine the
|best of both:
|> - The initial consent is established by ICE connectivity checks already.
|> - The receipt of any authenticated packet, including DTLS heartbeat, grants
|>   you consent to send more packets.
|> - If you doesn't receive any packet and consent is about to expire, send a
|>   STUN binding request that is comparatively less CPU intensive.
|>
|> Minimal overhead overall :)
|
|I disagree.  One of the merits of using the DTLS handshake to
|establish initial consent, authenticated packets to maintain it, and
|the DTLS heartbeat in the absence of authenticated packets is that it
|is all DTLS.  As someone who writes software, being able to keep all
|the logic constrained to a single software module is a significant
|improvement.

Well, my point is, for WebRTC you can also do the same optimization by confining the logic to the STUN module -- both can establish and maintain consent without generating additional traffic for majority of the use-cases.

From a security perspective, I don't see a real advantage of one over the other.

Muthu

|
|I don't believe the CPU cost of a DTLS heartbeat to be expensive
|enough to justify changes to this.  Given that you aren't using the
|CPU for crypto at all when you send it, I'm pretty sure that the CPU
|cost can be borne.