Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

From: Roman Shpount [mailto:[e-mail]]
Sent: Friday, August 22, 2014 11:39 AM

On Fri, Aug 22, 2014 at 12:21 PM, Makaraju, Maridi Raju (Raju) <[e-mail]<mailto:[e-mail]>> wrote:
>WebRTC browser - MUST
>WebRTC devide - SHOULD
>Other RTP entities (including WebRTC gateway) - MAY

What I still do not understand, is why a full ICE end point would not send consent messages? What is the reason for this? The security and operational benefits of this are clear and the incremental work in implementing consent is minimal.
<Raju>
A WebRTC-device could be a native app or in an embedded device where there could be some limitations about memory, cpu, energy and/or bandwidth. So, such a device could choose not to do consent freshness checks before sending data. Imagine an embedded device (Internet-of-things) sends some non real-time data (using webrtc data channel) every 30 secs; with consent check it first has to send a STUN req for consent and wait for response then send the data. In this case the consent checks add delay and overhead. IMHO, for WebRTC-device allowing the flexibility of no consent is a good idea; so a “SHOULD” is justified. But, I am ok to make consent for WebRTC-device a MUST too.
</Raju>

Also, in what circumstances would ICE-lite end point ever send consent? Where is this even defined? Also, if you are implementing sending STUN messages, why would you not implement the full ICE end point? Once implementation of sending and processing responses to STUN consent messages is done, incremental work to implement full ICE is minimal.
<Raju>
My understanding of draft-ietf-rtcweb-stun-consent-freshness-06.txt is: consent is unidirectional. So, if ice-lite endpoint wants to send data it needs to get consent if it does not trust the peer. A typical ice-lite endpoint has a public IP, but that does not mean peer gives automatic consent for it to send data or there are no security issues.
The reason why I am ok here for “MAY” instead of “MUST/SHOULD” is to allow the possibility for the WebRTC-gateway to be in a completely trusted network (enterprise network?) or some other mechanisms (like LTE EPC network) are there to make the network safe and secure (even if the client is not).
</Raju>

BR
Raju
And finally, what does any of this have to do with type of WebRTC end point? Browsers and devices must implement full ICE and thus must implement consent. Other RTP endpoints, may implement ICE-lite and skip consent, but ideally should implement full ICE and consent. I also believe all of this is already in the specification.
_____________
Roman Shpount