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

On Nov 26, 2013, at 11:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

> Hi Bernard,
> 
> Yes, this needs to be discussed further. With DTLS, there is no need to send consent checks if authentic SRTP/SRTCP packets are being received.  we may also want to compare DTLS heartbeat mechanism with STUN consent. Some of my observations:
> 
> [1] Remote peer may or may not support DTLS heartbeat. 
> [2] DTLS heartbeat can only be sent if remote peer accepts heartbeat request. 
> 
> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.
> 
> [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.
> 
> [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. 
> 
> [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS heartbeat API. 
> 
> [4] and [5] need enhancement in OpenSSL.
As you say: This is just an implementation issue of one particular implementation, not an issue with the protocol itself...

Best regards
Michael
> 
> -Tiru.
> 
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Thursday, November 21, 2013 12:02 AM
> To: Martin Thomson
> Cc: Magnus Westerlund; draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.org; Eric Rescorla
> Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
> 
>> I think that it's at least in good enough shape to put up for wider discussion.
>> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
>> 
>> Overall, I think that this is cleaner. The main advantage is that any
>> authenticated data counts toward refreshing consent. That means zero
>> overhead in many common cases.
> 
> [BA] I have to agree that it is worth discussing, particularly given the potential for zero additional overhead. 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 