Subject: [BEHAVE] TWIST and TURN

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 Mar 2008 19:48:26 -0400

Howdy,
I have submitted a draft as a straw-man, outlining an alternative to TURN-tcp called TWIST; and since it does TCP, it can also do UDP (or any transport for that matter), and it does IPv4/v6.

I am not strongly tied to the proposed encapsulations, details or specific choices in TWIST, and I'm sure there's something I left out or overlooked or whatever, but this is just a straw-man.  The basic thing I'm tied to is doing a relay below the TCP layer.  I also apologize for the length of this straw-man - I thought more was better.

Since I can never seem to get the ID-submission tool to parse my author info for drafts, it is in the manual submission process and can be found here for the next couple days:
http://www3.ietf.org/proceedings/staging/draft-kaplan-behave-twist-00.txt

Comments welcome, of course.

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 26 Mar 2008 22:00:54 -0400

A few quick questions/comments based on a very quick read through the  
draft:

1. As I understand it, the main difference between TWIST and TURN are  
the encapsulation formats for data traffic. TURN uses app/TURN/UDP/IP  
(where the TURN message is either a Send/Data indication or a  
ChannelData msg), while TWIST uses app/transport/UDP/IP or app/ 
transport/IP/ESP/UDP/IP. Both use STUN for control messaging. Do you  
agree? (Later: Another difference is that you support only UDP  
transport to the TWIST server).

2. A couple of months ago, I asked the WG if we should remove the  
ChannelData msg from TURN to simplify it. The response was no,  
because people wanted something with low overhead. TWIST seems to  
have even more overhead than TURN. Any comments?

3. How do you specify the peer in TWIST transport mode encapsulation?  
It seems you can specify the peer's port number, but not the peer's  
address.

4. You talk about two possible implementation methods on the client:  
embedding TWIST into the OS's stack, and using a "shim" layer. What  
about just adding a layer below the application?

- Philip

On Wed, 26-Mar-08, at 19:48 , Hadriel Kaplan wrote:
> Howdy,
> I have submitted a draft as a straw-man, outlining an alternative  
> to TURN-tcp called TWIST; and since it does TCP, it can also do UDP  
> (or any transport for that matter), and it does IPv4/v6.
>
> I am not strongly tied to the proposed encapsulations, details or  
> specific choices in TWIST, and I'm sure there's something I left  
> out or overlooked or whatever, but this is just a straw-man.  The  
> basic thing I'm tied to is doing a relay below the TCP layer.  I  
> also apologize for the length of this straw-man - I thought more  
> was better.
>
> Since I can never seem to get the ID-submission tool to parse my  
> author info for drafts, it is in the manual submission process and  
> can be found here for the next couple days:

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 Mar 2008 22:47:27 -0400

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]]
>

Sort of - it's mostly about relaying at a different layer, so the server doesn't have to terminate TCP sockets and all that implies.  But yes, for UDP applications, TWIST is basically just a potentially different encap format (the RFC3948 one), but for "TWIST-transport mode" it could be identical to TURN-udp's channel header encapsulation.

But the TWIST draft also currently specifies one TWIST connection = 1 peer connection.  I'm not ultra tied to that, but I think it's more amenable to firewall policies, which may want to stop a TWIST client from using TWIST to be a publicly reachable server for applications.  But I could easily be convinced that isn't a concern (I don't know much 'bout that - I focus on service providers, not Enterprises).  Clearly the rfc3948 mode supports multiplexing natively, but for TWIST-transport we'd have to use the channel-id header to do so.

I'm also not ultra tied to the encapsulation formats, or there being two of them - I just think it lets more network devices be TWIST servers cheaply, to increase the chance there is one.

> have even more overhead than TURN. Any comments?

For UDP, the TWIST-transport mode proposed could look exactly like TURN's channel-id mode, because the channel header just becomes a short-hand for the inner UDP header.  I like that channel header in TURN myself.  It's just at the wrong layer for TURN-TCP (it's inside TCP).  And you can't replace TCP's header with a channel-header clearly.

If anything, I would say remove the Send/Data from TURN-udp and only do channel headers, but it sounds like others don't want that.  Maybe there's a middle-ground where a Send is a request, from the client, returning a channel-id in response from the server, and from then on the client must use that channel-id for that peer tuple-set.  And for Data from the server, it carries a channel-id which the client must use for that peer tuple-set from then on, and Data becomes a responded-to request so the server knows the client got it. (or vice-versa, since the model in TURN is the client decides the channel-id number, for some reason I can't fathom)

> It seems you can specify the peer's port number, but not the peer's

For connect-mode, it's specified in the Allocate request, which has the PEER-ADDRESS attribute for TWIST, because 1 TWIST connection = 1 peer connection.  For listen-mode, if the client doesn't specify the peer to listen for, I forgot to put in that we'd have to decide between the TWIST server sending a STUN indication, or making the client fetch the info using STUN. (ie, Adam's idea for making these act like remote sockets)

> about just adding a layer below the application?

I'm not sure how that would work.  The application wants a TCP socket, for example - how does the shim layer above TCP get the TCP segments or IP packets encapsulated?  I would think it would have to be a TCP stack of its own, effectively just an integrated stack model again, no?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 Mar 2008 23:04:49 -0400

FYI, thanks to Dan's parsing talents, I have been able to submit it automatically, so it's now at:
http://www.ietf.org/internet-drafts/draft-kaplan-behave-twist-00.txt

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hadriel Kaplan
> Sent: Wednesday, March 26, 2008 7:48 PM
> To: Behave WG
> Subject: [BEHAVE] TWIST and TURN
>
> Howdy,
> I have submitted a draft as a straw-man, outlining an alternative to TURN-
> tcp called TWIST; and since it does TCP, it can also do UDP (or any
> transport for that matter), and it does IPv4/v6.
>
> I am not strongly tied to the proposed encapsulations, details or specific
> choices in TWIST, and I'm sure there's something I left out or overlooked
> or whatever, but this is just a straw-man.  The basic thing I'm tied to is
> doing a relay below the TCP layer.  I also apologize for the length of
> this straw-man - I thought more was better.
>
> Since I can never seem to get the ID-submission tool to parse my author
> info for drafts, it is in the manual submission process and can be found
> here for the next couple days:

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 28 Mar 2008 12:42:03 +0200

Hello,

Le Thursday 27 March 2008 01:48:26 ext Hadriel Kaplan, vous avez écrit :
> Howdy,
> I have submitted a draft as a straw-man, outlining an alternative to
> TURN-tcp called TWIST; and since it does TCP, it can also do UDP (or any

   The main motivation for TWIST is to put as little processing burden
   on the TWIST servers as possible, regardless of whether they are
   implemented in hardware or software, to increase the capacity and
   scalability on such servers.  The reason for this is to reduce
   operator cost, because the business case for a network provider
   deploying TURN or [TEREDO] or any network relay server type is very
   weak.

Teredo relays decapsulate IP packets into UDP/IPv4 and back, much like 
ESP-in-UDP tunnel mode, and, I guess, like the proposed TWIST tunnel mode. Why 
would Teredo scale any worse (or any better) than TWIST then? Teredo relays 
only handle datagrams - they don't care about the transport layer.

   [for example, there are no public TEREDO relays available currently,
    as far as this author is aware]

Last time I checked, there were a bunch of them. Look for 2001:0::/32 exports 
in the DFZ.

   Relaying is mainly for the application's benefit, and thus the major
   brunt of the work should be performed by the application or host it 
   resides on, rather than the relay server.

I agree that relaying is for the application's benefit. Well, the entire 
network is for the application benefit anyway :) However, this formulation 
blurs the distinction between end applications and end nodes.

Transport protocols are usually handled in "node-wide" IP stacks, rather than 
in the applications themselves. History of the BSD socket API, performance, 
code factorization, port numbers allocation... many reasons _not_ to change 
this design.

   It should be noted that a TWIST relay server is still implementable
   by applications at the OS user-layer of common personal computers,
   for example for P2P applications, with caveats.  The TWIST client
   can also be implemented in applications using standard TCP/IP stacks
   found in major Operating Systems, albeit with a sub-layer shim
   similar to IPSEC VPN software; or it can be integrated into a TCP/IP
   stack as a new socket type with less application involvement; or it
   can be implemented in a fully-integrated system.  This document
   mainly describes the behavior of a new TCP/IP stack called a "TWIST
   Stack" and a VPN-style shim called a "TWIST Shim". 

Operating systems typically provide some way to create a virtual IP interface. 
This works fairly well for IPsec tunnel mode, or to Teredo. However, I 
believe that does not work for transport mode. Also, virtual IP interfaces 
get traffic from, normally, every applications on the node.

How would tunnel mode work, by the way? It would need an IP address per 
client, I expect? 

> doing a relay below the TCP layer.  I also apologize for the length of this
> straw-man - I thought more was better.

I am confused as to what you are trying to achieve. From your earlier 
comments, I understand your -very legitimate (IMHO)- concerns regarding TURN 
TCP-to-UDP. I don't understand how this would solve it though. TURN 
TCP-to-UDP is used when the TURN client can ONLY use TCP to reach the TURN 
server, hence any kind of UDP encapsulation is impossible.

Obviously, if it works, TURN clients ought to use UDP-to-UDP and TCP-to-TCP. 
UDP-to-TCP is already forbidden by the TURN draft - rightfully so. TCP-to-UDP 
is a -disputed- fallback mechanism.

Regards,

-- 
Rémi Denis-Courmont

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Mar 2008 10:38:35 -0400

> From: Rémi Denis-Courmont [mailto:[email-masked]]
>

For TEREDO relay, it's no different in scalability - that's what I like about TEREDO, but TEREDO does not handle IPv4-IPv4 NAT traversal, which is a more near-term problem.  I didn't mean to imply TWIST scales better than TEREDO; I meant that TWIST needs to scale really well because any relay type has a weak business case for a network operator.

For IPv4 NAT, providing a whole IPv4 public address per NATed client would not scale, clearly (in a different context of "scale").

> Last time I checked, there were a bunch of them. Look for 2001:0::/32

Cool - can you post which relays those are? (where)  I know there are servers, but not relays. (I don't have access to the ipv6 route table)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Mar 2008 11:13:07 -0400

> code factorization, port numbers allocation... many reasons _not_ to

Agreed, and I don't.  That's why I propose a VPN-like shim.

> get traffic from, normally, every applications on the node.

So you're saying they get all application traffic regardless of destination?  That would still work for TWIST.  But as far as I've seen, they install a host IP for themselves for a loopback, and the routes they can reach through the VPN tunnel to that IP; so that your application when it sends something to an address in that VPN subnet gets routed to the VPN shim loopback, and then the VPN shim encapsulates and uses the same route table to reach the other tunnel end (based on the outer addresses, obviously).

> How would tunnel mode work, by the way? It would need an IP address per

Nope. I assume you mean how would it work on the relay?  The relay would have to do something tunnel relays don't normally do, which is tie an IP plus port number to the tunnel, instead of just IP.  I don't know if all of them can do that in hardware.  The hardware I've seen at the companies I've worked at currently and previously can, but I don't know how large the population is.  As I noted in the email, I'm not tied to any specific scheme - I want to offer whatever will get the largest population of possible relays.

> specific

This doesn't address that.  I'm not convinced it needs to address that.  For one because I am not convinced it's a problem that should be solved by the IETF, but for another TWIST is not a proposal to replace TURN.  To do TCP-UDP, you basically need to terminate the TCP socket and relay above it, as TURN does.  I think some hardware could do that, possibly with some very ugly TCP ACK-ing behavior and not really complying with TCP frankly, or just poor scalability - but that's the price to pay for doing something like that and doing it at that layer.  TWIST is just another STUN extension for relaying, for a more scalable relay approach.

> is a -disputed- fallback mechanism.

Sure, but even UDP-UDP implies a specific TURN server architecture that is not as widely available as tunnel-mode hardware.  For TURN TCP-TCP, it's even more the case.  (my company happens to be able to do them both, but I think this is the type of thing we should let as many hardware implementations do as possible, and even for my hardware TWIST would perform better I think)  So if TWIST can do the TCP-TCP, where the TCP is encapsulated in UDP for the TWIST connection, then I don't see why it wouldn't also be able to handle UDP-UDP.  And for transport-mode, it could happen to look exactly like TURN if we want.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Mar 2008 22:28:28 -0400

> So you're saying they get all application traffic regardless of
> destination?  That would still work for TWIST.  But as far as I've seen,
> they install a host IP for themselves for a loopback, and the routes they
> can reach through the VPN tunnel to that IP; so that your application when
> it sends something to an address in that VPN subnet gets routed to the VPN
> shim loopback, and then the VPN shim encapsulates and uses the same route
> table to reach the other tunnel end (based on the outer addresses,
> obviously).

Ahh, I think I know what you mean - we're talking across each other.  You mean as in an IPSEC vpn, such as a transport-mode IPSEC connection, or one using an SPD on the host to decide.  Sorry, I knew using the same terms as IPSEC in the TWIST draft would confuse that.  I don't mean that.  On the wire, the TWIST tunnel-mode would happen to look a heck of a lot like UDP encapsulated IPSEC ESP tunnel-mode.  That was by design, in the hopes of covering/including vendors who have IPSEC hardware to be able to be TWIST relays.  On the host client, it is not one.  It could be implemented any number of ways there I think, including a tun/tap driver, or some lower shim, or in the stack itself, or whatever.

The thing I was trying to describe would bind itself to a UDP socket of the main stack, to get received UDP packets from the TWIST server delivered to it and send UDP packets to the TWIST server, and it would redeliver them de-capsulated as a virtual interface.  That virtual interface is a virtual int  bound below the regular IP stack, and is where the app sends/receives data it wants to be relayed, and it does that through its normal stack by addressing them to that virtual interface's "remote" IP (which I am proposing be a well-known one).  That may well not be normal.  It may be a wrong way to go.  But it's not germane to the TWIST proposal.  I don't care much about how that works (I don't write clients :) - so long as the app can use its regular TCP/IP stack but they end up encapsulated to a TWIST server.

-hadriel

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 31 Mar 2008 08:47:11 +0300

Le Friday 28 March 2008 16:38:35 ext Hadriel Kaplan, vous avez écrit :
> For TEREDO relay, it's no different in scalability - that's what I like
> about TEREDO, but TEREDO does not handle IPv4-IPv4 NAT traversal, which is
> a more near-term problem.

That depends on which side you look at it: From below, Teredo _only_ does 
IPv4-IPv4 NAT traversal. From above, it only provides IPv6, which is not good 
if you want to run an IPv4-only application.

On the other hand, it is doubtful that a plain old IPv4-only application would 
ever handle TURN, TWIST or whatever else either, anymore than IPv6 and 
Teredo.

(...)
> Cool - can you post which relays those are? (where)  I know there are
> servers, but not relays. (I don't have access to the ipv6 route table)

Neither do I have a BGP table. But I still have traceroute - ending at Funet 
in my case. I know at least HotNIC, Funet, IABG Teleport and ConsulIntel are 
operating relays. This is not my business though, the ipv6-ops mailing (!= 
IETF v6ops) would be a better place for details.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 31 Mar 2008 09:08:23 +0300

Le Friday 28 March 2008 17:13:07 ext Hadriel Kaplan, vous avez écrit :
> > believe that does not work for transport mode. Also, virtual IP
> > interfaces get traffic from, normally, every applications on the node.
>
> destination?

Well no - it still follows the routing table, so in principle, you could use a 
certain tunnel only toward a certain (set of) destination(s):

> That would still work for TWIST.  But as far as I've seen, 

As it happens, VPNs are usually configured to catch everything as a security 
policy, which is indeed only a policy, not a built-in limitation. This 
however would add some interesting intricacies:

First, issues with potential RFC1918 address spaces overlap are likely if 
using an IPv4 VPN from an IPv4 NATed network. I know (through my online 
gaming brother) that Hamachi basically is some sort of proprietary 
Teredo-with-authentication service providing an IPv4 overlay. It hijacks the 
5.0.0.0/8 address space - not something an IETF draft can afford, I'm afraid.

Second, tunnel negotiation would need to be integrated into, say SIP O/A. I 
know there is Makoto&Dan's draft to set up a "generic" tunnel, but I suspect 
a more ICE-like negotiation would work better - the receiving endpoint 
probably wants to know why to setup a tunnel (voice call? file transfer?) 
before it actually sets it up.

Third, using IP tunneling may stumble upon the same integration issues as 
IPsec has had compared to TLS - it's quite do-able if you have full control 
over the whole software stack, but it's quite tricky for third party software 
vendors.

> Nope. I assume you mean how would it work on the relay?  The relay would
> have to do something tunnel relays don't normally do, which is tie an IP
> plus port number to the tunnel, instead of just IP.  I don't know if all of
> them can do that in hardware.  The hardware I've seen at the companies I've
> worked at currently and previously can, but I don't know how large the
> population is.  As I noted in the email, I'm not tied to any specific
> scheme - I want to offer whatever will get the largest population of
> possible relays.

That's another related issue. Following their routing table, the client would 
assume *any* IP packets toward a given destination must travel through the 
tunnel. I am not sure how that would fit with a TURNish/SOCKSish port 
allocation schema.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Mar 2008 21:00:38 -0400

> Sent: Monday, March 31, 2008 2:08 AM
>

Again, and I apologize if the TWIST draft isn't clear on this, but it's not a "tunnel" really.  It's an encapsulation format.  The "TWIST-tunnel mode" just happens to look like IPSEC tunnel-mode encapsulation (on purpose), but it is not actually an L3 tunnel.  There are no local routes installed of networks "beyond" the tunnel end, including none for the peer, for example.  If the shim model is implemented in a host, for example, the application sends its data to a "well-known" address for the shim, to be reserved by IANA possibly.

> before it actually sets it up.

The TWIST-allocated transport address is just another public relayed candidate address it can use for ICE, if that's what it's doing.  It's similar to TURN in that respect.  The far-end peer does not need to implement TWIST at all - it doesn't know anything's different.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Mar 2008 21:13:11 -0400

> ever handle TURN, TWIST or whatever else either, anymore than IPv6 and

It doesn't need to be an "IPv4-only" application - but an IPv6-capable application had better be able to talk to IPv4-only networks/hosts/apps, if it wants to actually talk to something more than a tiny fraction of the Internet for the next untold years.  TIST lets it do that.  TWIST lets it do that without the IPv4-peer being aware of this.  TWIST lets it do that using IPv6 "from below" without an IPv4 host address of its own at all "below", in fact. (which I only point out because a dual-stack is ok, but if the dual-stack has an IPv4 address, it begs the question why it should bother using its IPv6 one)

-hadriel