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

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Aug 2014 08:10:03 -0700

This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness
(available at
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/).
Please review the document and send comments to the list by September 10,
2014.

thanks,

Ted Hardie

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Aug 2014 14:06:22 +0000

Hi,

The draft says:

“WebRTC endpoints are required to support full ICE as specified in
                section 3.4 of [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.”

The draft also talks about “WebRTC implementations” and “WebRTC browsers”.

We need to make sure that the terminology is aligned with draft-ietf-rtcweb-overview (for example, draft-ietf-rtcweb-overview does not talk about “WebRTC endpoints”), which also may be impacted based on the outcome of the current terminology/gateway discussion.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 14. elokuuta 2014 18:10
To: [email-masked]; Sean Turner; Cullen Jennings
Subject: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness (available at http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/).  Please review the document and send comments to the list by September 10, 2014.
thanks,

Ted Hardie

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 20 Aug 2014 09:39:49 +0530

I believe draft-ietf-rtcweb-stun-consent-freshness deals with the WebRTC
browser. A WebRTC device (eg. a mobile phone) on the other hand, could run
a WebRTC browser and a JS and perform consent. Similarly, a WebRTC endpoint
(whatever that gets defined as) might also perform consent, while a WebRTC
gateway might not, and how consent applies to those should get specified in
the document(s) that define those requirements (note: the gateway referred
to in draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway).

So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC
endpoint and WebRTC implementation with WebRTC browser, IMHO.

Muthu

On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg <
[email-masked]> wrote:

>                 section 3.4 of [I-D.
> ​​
> ietf-rtcweb-transports].  However, when WebRTC
>
> We need to make sure that the terminology is aligned with
> draft-ietf-rtcweb-overview (for example,
> ​​
> draft-ietf-rtcweb-overview does not talk about “WebRTC endpoints”), which
> also may be impacted based on the outcome of the current
> terminology/gateway discussion.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Ted Hardie
> *Sent:* 14. elokuuta 2014 18:10
> *To:* [email-masked]; Sean Turner; Cullen Jennings
> *Subject:* [rtcweb] WG Last Call for
> draft-ietf-rtcweb-stun-consent-freshness
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Aug 2014 09:44:15 +0200

On 08/20/2014 06:09 AM, Muthu Arul Mozhi Perumal wrote:
> I believe draft-ietf-rtcweb-stun-consent-freshness deals with the
> WebRTC browser. A WebRTC device (eg. a mobile phone) on the other
> hand, could run a WebRTC browser and a JS and perform consent.
> Similarly, a WebRTC endpoint (whatever that gets defined as) might
> also perform consent, while a WebRTC gateway might not, and how
> consent applies to those should get specified in the document(s) that
> define those requirements (note: the gateway referred to in
> draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway).

Note: In terms of conformance requirements, "might" and "might not" are
completely equivalent (2119 style: MAY - there is no MAY NOT).

>
> So, draft-ietf-rtcweb-stun-consent-freshness should just replace
> WebRTC endpoint and WebRTC implementation with WebRTC browser, IMHO.
>
> Muthu
>
> On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>      
>
>     The draft says:
>
>      
>
>     ​ ​
>     ​ ​
>     draft-ietf-rtcweb-overview does not talk about “WebRTC
>     endpoints”), which also may be impacted based on the outcome of
>     the current terminology/gateway discussion.
>
>      
>
>     Regards,
>
>      
>
>     Christer
>
>      
>
>      
>
>     *From:*rtcweb [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Ted Hardie
>     *To:* [email-masked] <mailto:[email-masked]>; Sean Turner;
>     Cullen Jennings
>     This starts a WG Last Call for
>     draft-ietf-rtcweb-stun-consent-freshness (available at
>     Please review the document and send comments to the list by
>     September 10, 2014.
>
>     thanks,
>
>     Ted Hardie
>
>
>     [email-masked] <mailto:[email-masked]>

-- 
Surveillance is pervasive. Go Dark.

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 20 Aug 2014 22:07:03 +0530

Hi Muthu,

I agree with Harald that WebRTC endpoint & WebRTC gateway may implement ice-lite and so, there is no need to send consent check. IIUC, the intention of the draft is to mention that Full ICE supporting WebRTC entities MUST support consent check. 

I think that the following changes will be sufficient for the below comment:

1)      WebRTC endpoint & WebRTC implementation replaced by WebRTC devices. Please note that WebRTC browser is a webrtc device but not the other way around. 

2)      Add the statement that  Full ICE supporting WebRTC entities MUST support consent freshness. This statements will be useful for WebRTC Endpoint or WebRTC gateway which supports Full ICE.

Thanks

Partha

From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Wednesday, August 20, 2014 1:14 PM
To: [email-masked]
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

I believe draft-ietf-rtcweb-stun-consent-freshness deals with the WebRTC browser. A WebRTC device (eg. a mobile phone) on the other hand, could run a WebRTC browser and a JS and perform consent. Similarly, a WebRTC endpoint (whatever that gets defined as) might also perform consent, while a WebRTC gateway might not, and how consent applies to those should get specified in the document(s) that define those requirements (note: the gateway referred to in draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway).

Note: In terms of conformance requirements, "might" and "might not" are completely equivalent (2119 style: MAY - there is no MAY NOT).

So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC endpoint and WebRTC implementation with WebRTC browser, IMHO.

Muthu

On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg <[email-masked]> wrote:

Hi,

The draft says:

                section 3.4 of [I-D.

​ ​

We need to make sure that the terminology is aligned with draft-ietf-rtcweb-overview (for example, 

​ ​

draft-ietf-rtcweb-overview does not talk about “WebRTC endpoints”), which also may be impacted based on the outcome of the current terminology/gateway discussion. 

Regards,

Christer

thanks,

Ted Hardie

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Thu, 21 Aug 2014 09:46:19 +0530

The elementary entity that needs to perform consent is a WebRTC entity that
runs untrusted applications -- essentially a WebRTC browser. Other entities
may perform consent as a consequence of them running a browser or because
they want to use it to compute RTT or whatever and not simply because they
support full ICE. This elementary entity is the target for the consent
draft and I don't think the draft should convolute it any further. Of
course, adding some text that other WebRTC entities may perform consent for
the above said reasons could help, I think.

Muthu

On Wed, Aug 20, 2014 at 10:07 PM, Parthasarathi R <
[email-masked]> wrote:

>  Hi Muthu,
>
>
>
> I agree with Harald that WebRTC endpoint & WebRTC gateway may implement
> ice-lite and so, there is no need to send consent check. IIUC, the
> intention of the draft is to mention that Full ICE supporting WebRTC
> entities MUST support consent check.
>
>
>
> 1)      WebRTC endpoint & WebRTC implementation replaced by WebRTC
> devices. Please note that WebRTC browser is a webrtc device but not the
> other way around.
>
>
>
> 2)      Add the statement that  Full ICE supporting WebRTC entities MUST
> support consent freshness. This statements will be useful for WebRTC
> Endpoint or WebRTC gateway which supports Full ICE.
>
>
>
> Thanks
>
> Partha
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Harald
> Alvestrand
> *Sent:* Wednesday, August 20, 2014 1:14 PM
> *To:* [email-masked]
> *Subject:* Re: [rtcweb] WG Last Call for

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Aug 2014 11:21:45 -0700

On 20 August 2014 21:16, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> runs untrusted applications -- essentially a WebRTC browser.

That is incorrect.  Any entity that receives peer transport
information from elsewhere needs to perform consent.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Aug 2014 14:25:32 -0400

> information from elsewhere needs to perform consent.
All entities receive peer transport information from elsewhere, including
gateways running ICE-Lite. Does it mean all of them need to perform consent?

Generally it would be trivial to use any public VoIP service to force it to
send RTP traffic anywhere. It is not like this is a new problem.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Aug 2014 12:36:27 -0700

> gateways running ICE-Lite. Does it mean all of them need to perform consent?

That's the logical conclusion, yes.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 22 Aug 2014 10:55:53 +0530

ICE-lite entities don't even perform connectivity checks. Requiring they
perform consent freshness doesn't seem to make sense to me (of course, we
can come up with a new spec ICE-lite-with-consent, but that's a different
problem).

I am not saying you can't spoof a public VoIP service to send RTP anywhere.
Legacy ICE entities perform connectivity checks today and not consent and
consent freshness. Do we want to make them more secure? Sure. It however is
a problem of different scope and need to be solved in MMUSIC or elsewhere,
IMHO.

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

Thoughts?

Muthu

---

From: Roman Shpount <[email-masked]>
Date: Fri, 22 Aug 2014 09:37:11 -0400

On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal <
[email-masked]> 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
 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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Aug 2014 15:59:09 +0000

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 [[email-masked]] on behalf of Roman Shpount [[email-masked]]
Sent: Friday, 22 August 2014 4:37 PM
To: Muthu Arul Mozhi Perumal
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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

 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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 22 Aug 2014 16:18:23 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday, 22 August 2014 9:29 pm
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

Hi,

Regards,

Christer

________________________________
From: rtcweb [[email-masked]<mailto:[email-masked]>] on behalf of Roman Shpount [[email-masked]<mailto:[email-masked]>]
Sent: Friday, 22 August 2014 4:37 PM
To: Muthu Arul Mozhi Perumal
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

My take:
WebRTC browser - MUST
WebRTC devide - SHOULD

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 22 Aug 2014 16:21:59 +0000

>Other RTP entities (including WebRTC gateway) - MAY

+1

From: rtcweb [mailto:[email-masked]] On Behalf Of Muthu Arul Mozhi Perumal
Sent: Friday, August 22, 2014 12:26 AM
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

ICE-lite entities don't even perform connectivity checks. Requiring they perform consent freshness doesn't seem to make sense to me (of course, we can come up with a new spec ICE-lite-with-consent, but that's a different problem).

I am not saying you can't spoof a public VoIP service to send RTP anywhere. Legacy ICE entities perform connectivity checks today and not consent and consent freshness. Do we want to make them more secure? Sure. It however is a problem of different scope and need to be solved in MMUSIC or elsewhere, IMHO.

My take:
WebRTC browser - MUST
WebRTC devide - SHOULD

Thoughts?

Muthu

On Fri, Aug 22, 2014 at 1:06 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Roman Shpount <[email-masked]>
Date: Fri, 22 Aug 2014 12:39:25 -0400

> >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.

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.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Aug 2014 10:13:28 -0700

> can come up with a new spec ICE-lite-with-consent, but that's a different

I never suggested that.  What I suggested was that they SHOULD be
performing consent checks.  The fact that they don't is what I would
term a "legacy requirement".  I don't think that we should be
extending this exception to any other entities.

The only reason that ICE-lite gets away with not sending checks is
that it trusts both the signaling entities and its peers.  That's
dangerous.  We interoperate with ICE-lite only because doing otherwise
would exclude more entities than we are willing to exclude.

The current text is fine.  It opens a minimal hole that acknowledges
the existence of the bad actors, but doesn't attempt to bestow any
kind of validity or legitimacy on them.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 22 Aug 2014 17:40:20 +0000

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

>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

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 23 Aug 2014 02:54:03 +0530

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:[email-masked]] 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: [email-masked]
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

   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 <[email-masked]>
Date: Friday, 22 August 2014 9:29 pm
To: Roman Shpount <[email-masked]>, Muthu Arul Mozhi Perumal
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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 [[email-masked]] on behalf of Roman Shpount
[[email-masked]]
Sent: Friday, 22 August 2014 4:37 PM
To: Muthu Arul Mozhi Perumal
Cc: [email-masked]
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
<[email-masked]> wrote:

My take:

WebRTC browser - MUST

WebRTC devide - SHOULD

 

_____________
Roman Shpount

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 25 Aug 2014 16:25:08 +0530

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 <[email-masked]

>  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
> 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.”
>
>
>
> 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:[email-masked]] *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:* [email-masked]
>    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
>
> *From: *Christer Holmberg <[email-masked]>
> *Date: *Friday, 22 August 2014 9:29 pm
> *To: *Roman Shpount <[email-masked]>, Muthu Arul Mozhi Perumal <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [rtcweb] WG Last Call for
>  ------------------------------
>
> *From:* rtcweb [[email-masked]] on behalf of Roman Shpount [
> [email-masked]]
> *Sent:* Friday, 22 August 2014 4:37 PM
> *To:* Muthu Arul Mozhi Perumal
> *Cc:* [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Aug 2014 08:43:33 -0400

> Other (WebRTC/non-WebRTC) entities - MAY
To be clear, my opinion is

Any WebRTC entity implementing full ICE - MUST
Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST NOT

This way we are not inventing entity types and not defining behaviors which
would never be used (such as sending consent from an end point which would
send no STUN requests otherwise). This will also reduce the number of
interop cases from four (full ICE with consent, full iCE without consent,
ICE-lite, ICE-lite with consent) to only two (full ICE with consent,
ICE-lite).
_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 25 Aug 2014 13:15:21 +0000

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Monday, August 25, 2014 7:44 AM

On Mon, Aug 25, 2014 at 6:55 AM, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
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

Option 2:

This way we are not inventing entity types and not defining behaviors which would never be used (such as sending consent from an end point which would send no STUN requests otherwise). This will also reduce the number of interop cases from four (full ICE with consent, full iCE without consent, ICE-lite, ICE-lite with consent) to only two (full ICE with consent, ICE-lite).
<Raju>
I prefer option 1, but ok with option 2 as well. I did not hear any objections to the rationale I voiced earlier for option 1, which is at http://www.ietf.org/mail-archive/web/rtcweb/current/msg12957.html
</Raju>

BR
Raju

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Aug 2014 10:59:46 -0400

On Fri, Aug 22, 2014 at 1:40 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>  *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.*
>
>
>
First of all I do not believe this use case is something that was covered
by WebRTC normal use cases  and does not comply with the consent freshness
draft (where messages need to be sent regularly regardless of data being
sent). This would mean that consent freshness will not introduce additional
delay for sending data, but it will introduce additional battery, memory,
CPU, network and other resource usage.

Second,  there is a need to maintain the communication channel through the
NAT routers which will require regular messages in both directions,
Freshness requests serve this purpose well.

Third, it is useful to know that remote party is still present and ready to
receive data. Otherwise you need to rely on message timeouts which can be
misleading.

Finally, I am not sure if p2p webrtc data channel is the best way to
implement internet of things data communications. Most likely you will need
a more efficient protocol for such an app. Such protocol should not affect
normal use cases for WebRTC.

_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Aug 2014 10:15:50 -0700

> Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST NOT

Let's try this instead:

Any WebRTC entity MUST implement full ICE

Any entity performing full ICE MUST implement consent

Done.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Aug 2014 13:54:17 -0400

> Any entity performing full ICE MUST implement consent

We are still going to get a fair number of WebRTC gateways that implement
ICE-lite who will disagree. Unless this group will outlaw ICE-lite the way
it did SDES-SRTP (for the very similar security reasons), the caveat for
ICE-lite should stay.
_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 25 Aug 2014 18:01:10 +0000

Agree with Roman.
I don’t think outlawing ICE-lite is acceptable.
Btw, why are we changing the topic from ICE-lite’s support of consent-freshness to WebRTC support of ICE-lite?! ☺

BR
Raju

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Monday, August 25, 2014 12:54 PM
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

On Mon, Aug 25, 2014 at 1:15 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Let's try this instead:

Done.

We are still going to get a fair number of WebRTC gateways that implement ICE-lite who will disagree. Unless this group will outlaw ICE-lite the way it did SDES-SRTP (for the very similar security reasons), the caveat for ICE-lite should stay.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Aug 2014 12:38:12 -0700

> I don’t think outlawing ICE-lite is acceptable.

I've not ever suggested that.  I'm only suggesting that ICE-lite ∉
WebRTC.  (That's U+2209, btw).

WebRTC devices might talk to non-WebRTC devices.  Some of those might
only do the minimal part of ICE that they can get away with.

Still, I don't see any reason to change any text here.

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 25 Aug 2014 21:30:14 +0000

I am not sure whether the -consent-freshness draft is the right place to require conformance to full ICE in order for something to be called a WebRTC endpoint. There are other drafts like -overview or -transport for this. The -consent-freshness draft should only make the link between implemented ICE flavor and implications for consent freshness support.

I therefore prefer Roman's proposal, but I am open to relaxing the MUST NOT.

Kind regards,
Uwe
________________________________
Von: ext Martin Thomson<mailto:[email-masked]>
Gesendet: ‎25.‎08.‎2014 19:16
An: Roman Shpount<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

Let's try this instead:

Done.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 26 Aug 2014 09:44:50 +0530

> Any WebRTC entity MUST implement full ICE

​The transport draft already has the following:

​   ICE [RFC5245] MUST be supported.  The implementation MUST be a full
   ICE implementation, not ICE-Lite.  A full ICE implementation allows
   interworking with both ICE and ICE-Lite implementations when they are
   deployed appropriately.

​It also says:

   This document focuses on the data transport protocols that are used
   by conforming implementations, including the protocols used for
   interaction with intermediate boxes such as firewalls, relays and NAT
   boxes.

"Conforming implementations" seem to mean any WebRTC entity. However, the
following limits it to only WebRTC devices (and leaves out WebRTC gateway,
in particular):

   This document describes requirements that apply to all WebRTC
   devices.​

We should probably sort this out the "full ICE" requirement in the
transport draft.

> Any entity performing full ICE MUST implement consent
I guess you mean any WebRTC entity (there may be other SIP entities doing
full ICE and nothing to do with WebRTC). If so, it works for me..

Muthu​

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 26 Aug 2014 10:37:41 +0530

On Tue, Aug 26, 2014 at 3:00 AM, Rauschenbach, Uwe (NSN - DE/Munich) <
[email-masked]> wrote:

>   I am not sure whether the -consent-freshness draft is the right place
> to require conformance to full ICE in order for something to be called a
> WebRTC endpoint.
>

​Agree. That should probably go into the transport draft,

> There are other drafts like -overview or -transport for this. The
> -consent-freshness draft should only make the link between implemented ICE
> flavor and implications for consent freshness support.
>

​Roman later clarified he just wants the consent draft not to specify any
additional requirement for ICE-lite. ICE-lite entities respond to consent
checks by definition. That's all.

Muthu​

> Von: ext Martin Thomson <[email-masked]>
> An: Roman Shpount <[email-masked]>
> Cc: [email-masked]

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 26 Aug 2014 10:59:05 +0000

> WebRTC.  (That's U+2209, btw).
<Raju>
WebRTC is defined by more than just ICE connectivity checks.
IMHO, Categorizing a class of devices as NOT WebRTC just because of ICE-lite is not right, while there is so much other functionality (codecs, data channels) that is common. Also, the converse is not true either; just because a class of devices support ICE-full does not equate them to WebRTC class.
So, IMHO there is no merit in (re)classifying WebRTC devices around ICE-lite.
I also want to point out that ICE-lite is part of ICE RFC and also WebRTC clients already have a way to negotiate ICE-lite.

In addition, draft-ietf-rtcweb-overview-11 added definition for 3 classes of webrtc devices with varying level of conformance while keeping the core webrtc conformance common. Won't rest of the specs like consent freshness, transports etc. refer to these classes of webrtc devices instead of just concentrating on just one type of webrtc device?

</Raju>

BR
Raju

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 26 Aug 2014 20:15:53 +0530

On Tue, Aug 26, 2014 at 4:29 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

> IMHO, Categorizing a class of devices as NOT WebRTC just because of
> ICE-lite is not right, while there is so much other functionality (codecs,
> data channels) that is common. Also, the converse is not true either; just
> because a class of devices support ICE-full does not equate them to WebRTC
> class.
> I also want to point out that ICE-lite is part of ICE RFC and also WebRTC
> clients already have a way to negotiate ICE-lite.
>
> In addition, draft-ietf-rtcweb-overview-11 added definition for 3 classes
> of webrtc devices with varying level of conformance while keeping the core
> webrtc conformance common. Won't rest of the specs like consent freshness,
> transports etc. refer to these classes of webrtc devices instead of just
> concentrating on just one type of webrtc device?
>

​Consent freshness is applicable to any WebRTC entity supporting full ICE.
A WebRTC browser/device as defined in the transport and overview drafts
support full ICE, so perform consent freshness. The requirements for other
WebRTC entities, including WebRTC gateway, is yet to be fully specified,
and the document that specifies them would also specify whether they
support full ICE or not (and hence whether they perform consent freshness
or not).

I don't see a problem with this approach.

If you have a better approach, do suggest the text.

Muthu ​

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Aug 2014 11:00:52 -0700

On 26 August 2014 07:45, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> Consent freshness is applicable to any WebRTC entity supporting full ICE. A
> WebRTC browser/device as defined in the transport and overview drafts
> WebRTC entities, including WebRTC gateway, is yet to be fully specified, and
> the document that specifies them would also specify whether they support
> full ICE or not (and hence whether they perform consent freshness or not).

Actually, that's probably the best approach: note that this applies -
and can be useful for - any ICE implementation.  And leave it at that
for this document.  The transports or security docs might make some
statements about mandating this mechanism.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 26 Aug 2014 19:21:40 +0000

Consent freshness is applicable to any WebRTC entity supporting full ICE. A WebRTC browser/device as defined in the transport and overview drafts support full ICE, so perform consent freshness. The requirements for other WebRTC entities, including WebRTC gateway, is yet to be fully specified, and the document that specifies them would also specify whether they support full ICE or not (and hence whether they perform consent freshness or not).

If you have a better approach, do suggest the text.
<Raju>
IHMO, the consent freshness and ICE-full should NOT be coupled together.
So, I propose the following approach which overlaps with yours.

The draft-ietf-rtcweb-stun-consent-freshness should just talk about consent freshness in general and if it is supported by an implementation then it should specify the behavior, but not tie it to ICE-full.

The draft-ietf-rtcweb-transports should allow both ICE-full and ICE-lite implementations for webrtc and defer who implements what to respective webrtc class specific drafts (e.g. I-D.alvestrand-rtcweb-gateways). IMO, this is because webrtc is much bigger than just how ICE is done and categorizing an implementation as non-WeRTC just because of ICE-lite is not right.

The draft-ietf-rtcweb-overview can specify some high-level requirements for various classes of webrtc implementations and/or defer them, in some cases, to respective drafts (like it already did with I-D.alvestrand-rtcweb-gateways).
</Raju>

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Aug 2014 07:20:46 +0000

Hi,

>> Consent freshness is applicable to any WebRTC entity supporting full 
>> ICE. A WebRTC browser/device as defined in the transport and overview 
>> drafts support full ICE, so perform consent freshness. The 
>> requirements for other WebRTC entities, including WebRTC gateway, is 
>> yet to be fully specified, and the document that specifies them would 
>> also specify whether they support full ICE or not (and hence whether they perform consent freshness or not).
>
> Actually, that's probably the best approach: note that this applies - and can be useful for - any ICE implementation.  And leave 
> it at that for this document.  The transports or security docs might make some statements about mandating this mechanism.

As long as the WebRTC entity supporting full ICE does not assume that the remote WebRTC entity (e.g. a WebRTC gateway) also supports full ICE (read: won't perform consent freshness).

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Aug 2014 11:08:43 -0700

> As long as the WebRTC entity supporting full ICE does not assume that the remote WebRTC entity (e.g. a WebRTC gateway) also supports full ICE (read: won't perform consent freshness).

The only way that ICE uses the checks that a remote peer generates is
to populate peer reflexive candidates.  It doesn't apply to consent.
I think we're safe there.