Subject: RE: [BEHAVE] TURN solution for home networks

From: <[email-masked]>
Date: Tue, 4 Dec 2007 01:35:37 +0200

Hi,

Mikael Latvala wrote:
>1. "[Client] needs to request each permission explicitly and 
>one at a time." 
>
>There are two problems with this restriction.
>
>A. Home owner cannot know beforehand from which IP address (external IP
>address) s/he is going to access the home network.

I don't think this is specific to home networks as such. The IP address
specific filtering at the TURN relay will basically make it impossible
to run any "generic" servers via TURN, since the server would need to
have a priori knowledge of IP addresses of the clients that may want to
talk to the server. For usages with something like ICE this is not a
problem as the peer address is always signaled before traffic via TURN
needs to flow. 

Dan Wing wrote:
>
>I would like folks to comment on your other points; the design 
>decisions were made on purpose but if others are finding TURN 
>won't meet their needs, we may need to have two 'profiles' of 
>TURN; one that has the restriction described in TURN and 
>another that does not require configuring permissions in the 
>TURN server.
>

It's clear that this is a deliberate design choise as stated already in
the abstract of TURN draft:

   The extension purposefully restricts the ways in
   which the relayed address can be used.  In particular, it prevents
   users from running general purpose servers on ports obtained from the
   TURN server.

What I would like to understand is where the requirement for this
restriction came from. Is it just that we do not want to standardize a
protocol which would allow bypassing firewall policies in this manner?
But is that going to help if people can use any similar proprietary
solutions for the same thing anyway? And is it necessary to make the
restriction normative for all usages of TURN, or could there be another
"profile" (as Dan says) of TURN where the client could request what kind
of filtering to the relay should apply? 

I agree that circumventing firewall policies is not a good goal, but I
think there are many NAT-only cases (such as home networks) where there
would be a clear benefit in being able to run servers via TURN in such a
way that any client can contact the server, and the server itself would
perhaps authorize the client.

Regards,
	Markus 

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 3 Dec 2007 19:42:33 -0800

The model that the TURN spec follows is this:
   TURN is a media-relay (or data relay) protocol. It is not a  
signaling relay protocol.
   TURN relays arbitrary data without inspecting it and relies on the  
permission model
   to prevent various DoS attacks against the client.
Note that this permission model is identical to the permission model  
used by many NATs and FWs.

To work with such a permission model, the best thing is to use ICE.
ICE can install the necessary permissions to work with TURN.

However, ICE requires a separate signaling channel.
This signaling channel can be implemented using a signaling relay.
This signaling relay looks superficially like TURN, but uses a  
different permission model.
In particular, this signaling relay understands the signaling  
protocol and can make
a sensible determination on when it is appropriate to relay a  
signaling message.

For example:
The SIP signaling relay is known as a SIP proxy.
The HIP group is looking at a signaling relay which relays only HIP  
messages and uses
the properties of the HIP protocol to avoid DoS attacks.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 4 Dec 2007 07:22:28 +0200

Le Tuesday 04 December 2007 05:42:33 ext Philip Matthews, vous avez écrit :
>    TURN is a media-relay (or data relay) protocol.
(...)
> To work with such a permission model, the best thing is to use ICE.
(...)
> However, ICE requires a separate signaling channel.

I believe it's quite irrelevant whether some protocol is "signaling" 
or "media". Afterall, when it look at SIP/RTP, SIP is signaling and RTP is 
data. Yet when you look at DNS/SIP, DNS is signaling and SIP is the 
payload/data :)

However, it is very relevant in the more general sense that signaling is 
always needed in some form. Independent of ICE and/or SIP, there must be some 
way to learn the IP and port of the TURN allocation. Even if TURN is 
modified/extended to relay unsolicited traffic, the need for signaling before 
TURN will not go away automagically. That is true even if you have a public 
unrestrained IP address, and don't (need to) use TURN. The only difference 
with TURN is: in addition to the IP address, the port number must also be 
carried, as TURN cannot allow static ports (lest we have one single TURN 
client per TURN server ;-) )

-- 
Rémi Denis-Courmont

---

From: <[email-masked]>
Date: Tue, 4 Dec 2007 08:25:33 +0200

Philip,

Instead of imposing a particular permission model in TURN it would make
more sense to specify a generic TURN "base class" protocol and then
specify a particular instance of this TURN base class protocol in
another spec like ICE or some other STUN usage spec.

This way we would not mix protocol specific issues with the deployment
issues, as is done currently in the TURN spec. I have not attended IETF
meetings for some time so things may have changed since then but I
clearly remember from the past that it was very much a no-no thing to
put deployment specific restrictions in protocols. Dave Clark et.al.
have even written a good paper about this, they call it a tussle space,
in a different context but still applicable to this scenario as well.

If the community working on the ICE spec wants to impose such
restrictions on the use of TURN relays, that is their decision. However,
this decision should have no bearing on other instances of STUN usage. 

You say that ICE has its own permission model. If that is the case, why
do we need to specify a particular permission in the current TURN spec?

/Mikael

>-----Original Message-----
>From: ext Philip Matthews [mailto:[email-masked]] 
>Sent: 04.12.2007 05:43
>To: Latvala Mikael (Nokia-NRC/Helsinki)
>Cc: Dan Wing; [email-masked]; Isomaki Markus (Nokia-SIR/Espoo)
>Subject: Re: [BEHAVE] TURN solution for home networks
>
>   TURN relays arbitrary data without inspecting it and relies 
>on the permission model
>Note that this permission model is identical to the permission 
>model used by many NATs and FWs.
>
>protocol and can make a sensible determination on when it is 
>appropriate to relay a signaling message.
>
>For example:
>The HIP group is looking at a signaling relay which relays 
>only HIP messages and uses the properties of the HIP protocol 
>to avoid DoS attacks.
>
>- Philip
>
>>> 1. "[Client] needs to request each permission explicitly 
>and one at a 
>>> time."
>>>
>>> A. Home owner cannot know beforehand from which IP address 
>(external 
>>> IP
>> I don't think this is specific to home networks as such. The IP 
>> address specific filtering at the TURN relay will basically make it 
>> impossible to run any "generic" servers via TURN, since the server 
>> would need to have a priori knowledge of IP addresses of the clients 
>> that may want to talk to the server. For usages with something like 
>> ICE this is not a problem as the peer address is always signaled 
>> before traffic via TURN needs to flow.
>>
>> Dan Wing wrote:
>>>
>>> decisions were made on purpose but if others are finding TURN won't 
>>> meet their needs, we may need to have two 'profiles' of TURN; one 
>>> that has the restriction described in TURN and another that 
>does not 
>>> require configuring permissions in the TURN server.
>>>
>>
>> It's clear that this is a deliberate design choise as stated already 
>> in the abstract of TURN draft:
>>
>> restriction normative for all usages of TURN, or could there be 
>> another "profile" (as Dan says) of TURN where the client 
>could request 
>> what kind of filtering to the relay should apply?
>>
>> think there are many NAT-only cases (such as home networks) where 
>> there would be a clear benefit in being able to run servers via TURN 
>> in such a way that any client can contact the server, and the server 
>> itself would perhaps authorize the client.
>>
>> Regards,
>> 	Markus
>>
>>
>>