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

[Muthu Arul Mozhi Perumal <[e-mail]>]

I thought a "SHOULD perform" is more appropriate for a WebRTC device as it
doesn't implement the public API and might run a proprietary/native app
running in a constrained environment and the overhead of performing the
periodic consent might overweigh the benefits. However, I don't have an
issue of making it a MUST -- at least no one has objected so far. I hear
the following options from the discussions so far:

Option 1:
WebRTC browser - MUST
WebRTC device - MUST
Other (WebRTC/non-WebRTC) entities - MAY

Option 2:
Any WebRTC entity doing full ICE - MUST
Other (WebRTC/non-WebRTC) entities - MAY

Obviously, #2 is stronger than #1 and also covers a WebRTC gateway doing
full ICE. I would like to hear from others as well..

Muthu

On Sat, Aug 23, 2014 at 2:54 AM, Parthasarathi R <[e-mail]
> wrote:

>  Hi Ram/Muthu,
>
>
>
> There is a terminology variation here. As per the current overview
> document, WebRTC device supports full WebRTC protocol requirement which
> includes consent-check. In case consent check is excluded from WebRTC
> device,  the new definition has to be provided for “WebRTC device” in
> –overview draft. I don’t think that WebRTC device definition has to be
> changed now.
>
>
>
> IMO, WebRTC device & WebRTC browser MUST support consent check. As
> discussed in another mail thread, there is an need to define “WebRTC
> endpoint” which relaxes the lot of WebRTC protocol requirement based on the
> specific deployment like Enterprise, LTE EPC. “WebRTC Endpoint” & “WebRTC
> Gateway” MAY support consent check.
>
>
>
> I have highlighted Full ICE as a criteria for “WebRTC Endpoint” & “WebRTC
> Gateway” in
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg12938.html as it
> helps the implementers to decide whether consent check has to be
> implemented in their “WebRTC Endpoint”/ “WebRTC Gateway” or not. As “WebRTC
> Endpoint” is yet to defined and “WebRTC gateway” is just now proposed in
> -11 overview draft,  I have proposed the text as
>
>
>
> “Full ICE supporting WebRTC entities  MUST support consent freshness.”
>
>
>
> Please let me your opinion on the same.
>
>
>
> Also, I agree with Muthu’s statement to indicates the other requirement
> for WebRTC entities to include consent check are:
>
> “to use the mechanism to make it more secure or compute RTT or carry
> network information”
>
>
>
>
>
> Thanks
>
> Partha
>
>
>
>
>
>
>
> *From:* rtcweb [mailto:[e-mail]] *On Behalf Of *Ram Mohan
> R (rmohanr)
> *Sent:* Friday, August 22, 2014 9:48 PM
> *To:* Christer Holmberg; Roman Shpount; Muthu Arul Mozhi Perumal
>
> *Cc:* [e-mail]
> *Subject:* Re: [rtcweb] WG Last Call for
> draft-ietf-rtcweb-stun-consent-freshness
>
>
>
> Right. I think we had discussed this in the past and added the below text
> in the draft
>
>
>
> " WebRTC endpoints are required to support full ICE as specified in
>
>    section 3.4 of [I-D.ietf-rtcweb-transports <http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-05#ref-I-D.ietf-rtcweb-transports>].  However, when WebRTC
>
>    endpoints interwork with other endpoints that support only ICE-lite
>
>    (e.g. gateways) those endpoints will not generate consent checks, but
>
>    just respond to consent checks they receive”
>
>
> Isn’t this sufficient ?
>
>
> Ram
>
>
>
> *From: *Christer Holmberg <[e-mail]>
> *Date: *Friday, 22 August 2014 9:29 pm
> *To: *Roman Shpount <[e-mail]>, Muthu Arul Mozhi Perumal <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [rtcweb] WG Last Call for
> draft-ietf-rtcweb-stun-consent-freshness
>
>
>
> Hi,
>
>
>
> An ICE-lite endpoint must already today *REPLY* to STUN requests - consent
> freshness does not change that.
>
>
>
> But, I don't think an ICE-lite endpoint shall be mandated to *SEND*
> consent freshness requests.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>  ------------------------------
>
> *From:* rtcweb [[e-mail]] on behalf of Roman Shpount [
> [e-mail]]
> *Sent:* Friday, 22 August 2014 4:37 PM
> *To:* Muthu Arul Mozhi Perumal
> *Cc:* [e-mail]
> *Subject:* Re: [rtcweb] WG Last Call for
> draft-ietf-rtcweb-stun-consent-freshness
>
> On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal <
> [e-mail]> wrote:
>
>  draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC
> browser more secure. It however allows an RTP endpoint (that also does ICE)
> to use the mechanism to make it more secure or compute RTT or carry network
> information or whatever. However, requiring every RTP endpoint perform it
> seems asking too much.
>
>
>
> My take:
>
> WebRTC browser - MUST
>
> WebRTC devide - SHOULD
>
> Other RTP entities (including WebRTC gateway) - MAY
>
>
>
>
>
>  I would say that all full ICE endpoint interworking with WebRTC MUST
> implement consent freshness. ICE-LITE will not implement, but MUST respond
> (unless someone defines it, but once you start sending STUN request you
> might as well do full ICE, so I do not see much point in it). And to
> conclude strongly encourage full ICE implementation for security and other
> reasons.
>
> _____________
> Roman Shpount
>
>
>