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

["Parthasarathi R" <[e-mail]>]

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