Subject: [rtcweb] Consent freshness for TURN servers

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Jun 2015 17:57:40 -0400

Hi All,

I wanted to see if there is a consent check issued by the TURN server to
verify that remote party is willing to accept media. Is this something that
is planned or do TURN servers suppose to rely that the clients sending
media through TURN servers will perform their own consent checks and simply
trust the client?

Regards,
_____________
Roman Shpount

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 23 Jun 2015 23:28:28 -0700

On 23-Jun-2015 02:57 pm, Roman Shpount <[email-masked]> wrote: 
> I wanted to see if there is a consent check issued by the TURN server to verify that remote party is willing to accept media. Is this something that is planned or do TURN servers suppose to rely that the clients sending media through TURN servers will perform their own consent checks and simply trust the client?

The TURN server doesn't know the ice-passwd between the two peers, which is necessary to create a valid STUN request (or to validate the STUN response).  If we decide it necessary, the TURN server could watch for consent check packets and tear down the channel binding if none seen in NNN seconds.

-d

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Jun 2015 18:51:58 -0400

On Wed, Jun 24, 2015 at 2:28 AM, 🔓Dan Wing <[email-masked]> wrote:

> The TURN server doesn't know the ice-passwd between the two peers, which
> is necessary to create a valid STUN request (or to validate the STUN
> response).  If we decide it necessary, the TURN server could watch for
> consent check packets and tear down the channel binding if none seen in NNN
> seconds.

Was there discussion already if consent is necessary for TURN servers? I am
trying to see if decision was already made or if the topic was not
discussed yet.

I can see how consent monitoring can be implemented by client sharing ICE
pwd with the TURN server via an additional command or via additional
parameter in Allocate or CreatePermission request.

Regards,
_____________
Roman Shpount

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 24 Jun 2015 18:13:46 -0700

On 24-Jun-2015 03:51 pm, Roman Shpount <[email-masked]> wrote: 
> On Wed, Jun 24, 2015 at 2:28 AM, 🔓Dan Wing <[email-masked] <mailto:[email-masked]>> wrote:
> On 23-Jun-2015 02:57 pm, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
> Was there discussion already if consent is necessary for TURN servers? I am trying to see if decision was already made or if the topic was not discussed yet.

To my knowledge, it has not been discussed.  Seems a good microphone discussion for Prague.

> I can see how consent monitoring can be implemented by client sharing ICE pwd with the TURN server via an additional command or via additional parameter in Allocate or CreatePermission request. 

I suppose we could do that, but sharing the ICE password with the TURN server feels wrong.  The TURN server does not, itself, generate traffic.  Because it doesn't generate traffic itself, I don't think it needs to have consent.  It may well be valuable for the TURN server to verify the client has obtained consent (by watching for consent request/response across the TURN server), but that seems more a firewall function and IETF typically shies away from defining firewall functions.

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 25 Jun 2015 11:52:55 +0200

On 06/25/2015 12:51 AM, Roman Shpount wrote:
>     > I wanted to see if there is a consent check issued by the TURN
>     server to verify that remote party is willing to accept media. Is
>     this something that is planned or do TURN servers suppose to rely
>     that the clients sending media through TURN servers will perform
>     their own consent checks and simply trust the client?
>
>     The TURN server doesn't know the ice-passwd between the two peers,
>     which is necessary to create a valid STUN request (or to validate
>     the STUN response).  If we decide it necessary, the TURN server
>     could watch for consent check packets and tear down the channel
>     binding if none seen in NNN seconds.
>
>
> Was there discussion already if consent is necessary for TURN servers?
> I am trying to see if decision was already made or if the topic was
> not discussed yet.

I thought it was obvious that TURN servers are outside both ICE
authentication flow and ICE consent flows - they just relay stuff, they
have no separate data-generating role.

If someone wants to make the argument that TURN servers need to have a
different role from just being a TURN server, that's an interesting
discussion to have - but I'd want to see the argument for this change in
the model (it's a CHANGE, and we're late in the process) clearly laid
out in text (preferably an I-D) before even accepting it as a discussion
topic.

Or to put it even more shortly: I think it's a bad idea, and we
shouldn't spend time discussing it until somoene explains to the group
why I might be wrong about that.

>
> I can see how consent monitoring can be implemented by client sharing
> ICE pwd with the TURN server via an additional command or
> via additional parameter in Allocate or CreatePermission request. 
>
> Regards,
> _____________
> Roman Shpount
>  
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 25 Jun 2015 12:30:06 +0000

+ 1
As I understand, periodic consent between peers are needed as there is no other mechanism to know the peer is still willing to receive and also allocated the resources for this peer.
However, in TURN case, TURN client and TURN server can use procedures in https://tools.ietf.org/html/rfc5766#section-7 to refresh the allocation with certain life time. This I believe serve the same purpose as consent; i.e. during that life time TURN server is willing to accept the content and keeps the allocation for the peer until the lifetime expires.

May be some guidance on the lifetime of the TURN allocations, to align with webrtc STUN consent timers, be suggested here in draft-ietf-rtcweb-stun-consent-freshness?
Also, please note that there is only one TURN allocation to be used to communicate with all peer candidates; so, a consent failure on one candidate does not automatically need freeing up of TURN resources.

BR
Raju

Or to put it even more shortly: I think it's a bad idea, and we shouldn't spend time discussing it until somoene explains to the group why I might be wrong about that.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Jun 2015 17:21:34 +0000

Hi,

I agree with Harald. On my opinion TURN is about NAT traversal, not traffic/consent policing.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Harald Alvestrand<mailto:[email-masked]>
Sent: ‎25/‎06/‎2015 11:53
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Consent freshness for TURN servers

On 06/25/2015 12:51 AM, Roman Shpount wrote:
On Wed, Jun 24, 2015 at 2:28 AM, 🔓Dan Wing <[email-masked]<mailto:[email-masked]>> wrote:

I thought it was obvious that TURN servers are outside both ICE authentication flow and ICE consent flows - they just relay stuff, they have no separate data-generating role.

If someone wants to make the argument that TURN servers need to have a different role from just being a TURN server, that's an interesting discussion to have - but I'd want to see the argument for this change in the model (it's a CHANGE, and we're late in the process) clearly laid out in text (preferably an I-D) before even accepting it as a discussion topic.

Regards,
_____________
Roman Shpount

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 25 Jun 2015 11:24:39 -0600

> why I might be wrong about that.

+1

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Jun 2015 10:26:39 -0700

On Thu, Jun 25, 2015 at 5:30 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>  + 1
>
> As I understand, periodic consent between peers are needed as there is no
> other mechanism to know the peer is still willing to receive and also
> allocated the resources for this peer.
>
> However, in TURN case, TURN client and TURN server can use procedures in
> https://tools.ietf.org/html/rfc5766#section-7 to refresh the allocation
> with certain life time. This I believe serve the same purpose as consent;
> i.e. during that life time TURN server is willing to accept the content and
> keeps the allocation for the peer until the lifetime expires.
>

​I'm a bit confused.  The TURN server and client interaction you cite seems
to handle the TURN server confirming that it is still willing to act on
behalf of the client until the state time, where the consent mechanisms are
for the client to confirm that a remote client is still willing to receive
data.  I don't see a reason to extend either to cover the other case.  What
am I missing?

regards,

Ted​

>
>
> May be some guidance on the lifetime of the TURN allocations, to align
> with webrtc STUN consent timers, be suggested here in
> draft-ietf-rtcweb-stun-consent-freshness?
>
> Also, please note that there is only one TURN allocation to be used to
> communicate with all peer candidates; so, a consent failure on one
> candidate does not automatically need freeing up of TURN resources.
>
>
>
> BR
>
> Raju
>
>
>
>
> Or to put it even more shortly: I think it's a bad idea, and we shouldn't
> spend time discussing it until somoene explains to the group why I might be
> wrong about that.
>
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 25 Jun 2015 18:44:41 +0000

+ 1

​I'm a bit confused.  The TURN server and client interaction you cite seems to handle the TURN server confirming that it is still willing to act on behalf of the client until the state time, where the consent mechanisms are for the client to confirm that a remote client is still willing to receive data.  I don't see a reason to extend either to cover the other case.  What am I missing?
[Raju] I am not suggesting extending one to cover the other. My comment is to support the opposite which supports Harald’s earlier comment. Basically what I tried to convey was, TURN has its own way of keeping the allocation fresh and no need to mix it with peer to peer consent. Sorry for the confusion.
BR
Raju

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Jun 2015 15:15:26 -0400

On Thu, Jun 25, 2015 at 5:52 AM, Harald Alvestrand <[email-masked]>
wrote:

> the model (it's a CHANGE, and we're late in the process) clearly laid out
> in text (preferably an I-D) before even accepting it as a discussion topic.
>
> spend time discussing it until someone explains to the group why I might be
> wrong about that.
>

I agree that consent monitoring by TURN server is not necessary. I just
wanted to know if anybody brought this up. From what I can see everybody
else thinks it is not needed so we can continue to live happily without
this.

Regards,
_____________
Roman Shpount