Subject: [BEHAVE] TURN solution for home networks

From: <[email-masked]>
Date: Tue, 27 Nov 2007 17:28:09 +0200

The current TURN specs says:

"Though originally invented for Voice over IP applications, TURN is
designed to be a general-purpose relay mechanism for NAT traversal."

Unfortunately this is not that obvious when one reads the current TURN
spec. This spec has the following limitations which make it unsuitable
for scenarios where the home owner wants to access services in the home
network from a remote location;

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.

B. Even if home owner did magically know all the external IP addresses,
all home automation and many AV based device would not be able to
request such permissions, because there are no mechanisms how home owner
could the devices what these external IP addresses are.

2. "A TURN server can then relay traffic between a reliable transport
used between the client and server (TCP or TLS over TCP), and UDP used
from server to peer."

Limiting the transport protocol to UDP between server and peer means for
example that peers behind corporate firewalls would not be able to
access the TURN server.

3. Last but not least, it has been pointed out to me that IESG won't
accept wordings such as 

"This insures that a client can't use a TURN server to run a traditional
server, and partially protects the client from DoS attacks."

as these restrictions are outside the scope of this spec.

There are three alternatives how we can correct the current situation
and make TURN-type solution applicable also for home networks:

1. Modify the existing draft-ietf-behave-turn-XX.txt (considering how
long the TURN work has been going on I see this very unlikely
alternative)
2. Create a new BEHAVE sponsored draft which addresses the home network
needs (Nokia preferred alternative)
3. Wait that some company creates an informational draft

My plan is to discuss about these three different alternatives in
Vancouver and hopefully get some kind of a rough consensus on how to go
forward. 

/Mikael

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 27 Nov 2007 09:31:44 -0800

> The current TURN specs says:

[snip]

> example that peers behind corporate firewalls would not be able to

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-behave-turn-tcp-00.txt

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Nov 2007 17:38:32 -0800

> Limiting the transport protocol to UDP between server and 
> peer means for example that peers behind corporate firewalls 
> would not be able to access the TURN server.

TURN does support the following scenario:

  Endpoint-A                              Endpoint-B
  TURN client---------TURN server---------peer
                 ^                   ^
                 |                   |
                TCP                 UDP

This allows Endpoint-A to be behind a firewall that only allows outgoing TCP
connections.

If Endpoint-B is also behind a firewall that only allows TCP, Endpoint-B would
also need to get a UDP address from its TURN server, resulting in a flow like
this:

  Endpoint-A        Endpoint-A's      Endpoint-B's      Endpoint-B
  TURN client-------TURN server-------TURN server-------peer
                ^                 ^                  ^
                |                 |                  |
               TCP               UDP                TCP

If you want TCP on the 'public' (peer) side of the TURN server, you need
TURN-TCP as Marc mentioned.  With TURN-TCP, you can do this:

  Endpoint-A        Endpoint-A's      Endpoint-B
  TURN client-------TURN server-------peer
                ^                 ^   
                |                 |   
               TCP               TCP  

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.

-d

---

From: David Miles <[email-masked]>
Date: Wed, 28 Nov 2007 14:21:28 +1100

Mikael,

You mentioned work is needed to address the home network needs - would  
we be able to spend some time discussing these? I'm interested to know  
the drivers for TURN vs STUN as I would have thought TURN would have  
been an undesirable solution.

Best Regards,

-David

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Nov 2007 13:00:38 -0500

inline:

> network from a remote location;

Can you clarify what you have in mind here?

It sounds like, there is a TURN server running in the home network, 
presumably accessible at some public IP address. The user takes their PC 
somewhere else, and wants to connect to their TURN server, obtain an IP 
address which is actually within their home network (presumably net-10 
or 192.168 for example) and then be able to access things like their 
home PC or NAS box as if they were on the home network? Sort of like a 
VPN, right?

If so, I think its fair to say that TURN by itself is not going to 
address this problem, and I don't think it should. There has been some 
other work on using SIP to establish IPSec VPN for remote access to home 
resources:

http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt

But perhaps you have a different use case in mind.

> address) s/he is going to access the home network.

Hmm, based on this question you definitely have a different picture in 
mind. In the scenario I outline above, the permissions would be opened 
for communicating with devices in the home, not for the remote client.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: <[email-masked]>
Date: Thu, 29 Nov 2007 02:07:10 +0200

David,

TURN is as undesirable solution for home networks as it is for SIP
traffic which is the concern of the current TURN spec. I would be more
that happy to use only STUN. Unfortunately STUN is just not enough,
AFAIK this is especially true in the States. 

My personal opinion is that the only reason we need to create TURN like
specs is to show operators and ISPs that 

      - IETF community is capable of creating a set necessary protocols
which allow the Internet community to circumvent the obstacles that
restrictive NATs introduce
	- the sooner the ISP and operators adopt the correct network
neutrality attitude, the faster the Internet ecosystem can benefit from
the fast last mile connections (xDSL, DOCSIS, fiber, WiMAX, etc.) which
shall also give a boost to operators' and ISPs' business

When saying operators and ISPs I am not claiming that every operator or
ISP places restrictions on the use of the Internet as in some parts of
the world the TURN specs have no validity. 

/Mikael

>-----Original Message-----
>From: ext David Miles [mailto:[email-masked]] 
>Sent: 28.11.2007 05:21
>To: Latvala Mikael (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: Re: [BEHAVE] TURN solution for home networks
>
>Mikael,
>
>You mentioned work is needed to address the home network needs 
>- would we be able to spend some time discussing these? I'm 
>interested to know the drivers for TURN vs STUN as I would 
>have thought TURN would have been an undesirable solution.
>
>Best Regards,
>
>-David
>
>> for scenarios where the home owner wants to access services in the 
>> home network from a remote location;
>>
>> B. Even if home owner did magically know all the external IP 
>> addresses, all home automation and many AV based device would not be 
>> able to request such permissions, because there are no 
>mechanisms how 
>> home owner could the devices what these external IP addresses are.
>>
>> Limiting the transport protocol to UDP between server and peer means 
>> for example that peers behind corporate firewalls would not 
>be able to 
>> access the TURN server.
>>
>> "This insures that a client can't use a TURN server to run a 
>> traditional server, and partially protects the client from DoS 
>> attacks."
>>
>> 2. Create a new BEHAVE sponsored draft which addresses the home 
>> network needs (Nokia preferred alternative) 3. Wait that 
>some company 
>> creates an informational draft
>>
>> Vancouver and hopefully get some kind of a rough consensus on how to 
>> go forward.
>>
>> /Mikael
>>
>>

---

From: <[email-masked]>
Date: Thu, 29 Nov 2007 03:03:25 +0200

Jonothan,

Axiom:

There is a network called the home network in a house. The home network
contains one Home Gateway (HG), which is typically a DOCSIS or xDSL
model, and one or more nodes (computers, servers or devices such as
refigerators, A/C controllers, security cameras, thermostats, heatpumps,
etc.) Whether all these devices have an IP address is irrelevant as long
as other nodes in the home network can communicate with such non-IP
based devices. HG forwards packets between the home network and the
Internet.

Use case:

Home owner visits some location outside his house and needs to access a
computer, server and/or device in the home network from this remote
location.

Now, as far as I have understood the TURN draft correctly, the current
TURN spec does not offer a solution for this use case. Furthermore, TURN
server cannot be run in the home network because nodes in the home
network are usually assinged with a private IP address.

What comes to the
http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt
the proposal has only two shortcomings: 
	A. It uses SIP as a control protocol
	B. It uses IPsec as a tunnel protocol

SIP is bad because legacy applications and most of the applications
created still today use domain names and DNS. Moving to SIP would mean
changes to every application. IPSec is bad, because it has to be UDP
encapsulated to sustain NAT enforced header changes but at the same time
large portion of firewalls, especially corporate ones, block any
outgoing UDP traffic.
 
/Mikael

>From: ext Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: 28.11.2007 20:01
>It sounds like, there is a TURN server running in the home 
>network, presumably accessible at some public IP address. The 
>user takes their PC somewhere else, and wants to connect to 
>their TURN server, obtain an IP address which is actually 
>within their home network (presumably net-10 or 192.168 for 
>example) and then be able to access things like their home PC 
>or NAS box as if they were on the home network? Sort of like a 
>VPN, right?
>
>If so, I think its fair to say that TURN by itself is not 
>going to address this problem, and I don't think it should. 
>There has been some other work on using SIP to establish IPSec 
>VPN for remote access to home
>resources:
>
>Hmm, based on this question you definitely have a different 
>picture in mind. In the scenario I outline above, the 
>permissions would be opened for communicating with devices in 
>the home, not for the remote client.
>
>-Jonathan R.
>
>
>--

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 28 Nov 2007 17:33:24 -0800

> computer, server and/or device in the home network from this remote

Here's an idea:  You assign an IPv6 address to each of your computer,
server and/or device, and then you can access all of them from anywhere
on the Internet.  A WRT45GL with OpenWRT with a free IPv6 tunnel from HE
or SixXS for your home, another free IPv6 tunnel from Freenet6 for your
laptop and you are all set.

---

From: <[email-masked]>
Date: Thu, 29 Nov 2007 08:51:22 +0200

:)

>
>Here's an idea:  You assign an IPv6 address to each of your 
>computer, server and/or device, and then you can access all of 
>them from anywhere on the Internet.  A WRT45GL with OpenWRT 
>with a free IPv6 tunnel from HE or SixXS for your home, 
>another free IPv6 tunnel from Freenet6 for your laptop and you 
>are all set.
>
>>