Subject: [tsvwg] Generic UDP tunneling (draft-manner-tsvwg-gut-00)

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 14 Sep 2009 17:16:27 +0300

Dear all,

We submitted the following draft and would appreciate feedback and 
comments from the community.

The spec is not purely a pen and paper exercise, we have a Linux 
implementation that indicates that the concept works quite nicely, at 
least with the hardware we tried it with (Linux end hosts, some 
out-of-the-box D-link and Linksys NAT boxes in between). We need to fix 
and add a few things, then we can release the implementation as open source.

http://www.ietf.org/id/draft-manner-tsvwg-gut-00.txt

cheers,
Jukka

-------------------------------

A new version of I-D, draft-manner-tsvwg-gut-00.txt has been successfuly 
submitted by Jukka Manner and posted to the IETF repository.

Filename:	 draft-manner-tsvwg-gut
Revision:	 00
Title:		 Generic UDP Tunnelling (GUT)
Creation_date:	 2009-09-14
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
Deploying new transport protocols on the Internet is a well-known
problem, as NATs and firewall drop packets with new protocol types.
Tunnelling over UDP is one way to make IP packets hide the actual
payload and enable end-to-end delivery.  This draft proposes a simple
UDP tunnelling encapsulation and end-host operation to enable new IP
payloads, e.g., new transport protocols, to be deployed on the
Internet.

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 25 Sep 2009 17:32:28 -0700

Hi Jukka,

I had discussed about a generic UDP tunneling scheme with a few IETF  
colleagues (including you) a couple of months ago, but the draft I  
started to write then got forgotten in my drawer.

Of course there is the main tussle aspect about whether starting to  
encapsulate protocols generally inside UDP in hopes of better  
middlebox traversal is the right step from the standardization  
viewpoint (as discussed in earlier BOFs and plenaries, I guess).  
Putting that question aside, here are some technical thoughts:

I'm a little doubtful about the idea of using a single UDP port for  
all protocols. The receiver of the UDP datagrams would need to carry  
out the de-multiplexing and forwarding to different protocol modules  
and manage the related state, which could as well be done  
"automatically" by the UDP implementatation, by using different port  
numbers for each protocol.

We had discussed a couple of ways for doing this:

1) simply allocate the needed range of UDP ports from IANA for  
different protocols (which might be wasteful), or

2) (in my opinion) more elegantly, have a separate initiation phase:  
first, a client sends a message to a well-known UDP port and asks what  
is the UDP port number for tunneling protocol X. If the client gets a  
positive response, it can start sending UDP-tunneled protocol packets  
directly to the returned port Y without additional GUT header  
overhead. In such system it would be easy to add new protocols for  
experimentation, for example just by adding new entries in a  
configuration file processed by a small application that listens to  
the queries at a well-known UDP port and responds by returning the  
port numbers for tunneling the configured protocols.

In any of the above cases, a strong advise should be given to first  
try if the native protocol works without UDP encapsulation, before  
going into UDP tunneling mode.

Other issue: I don't get the usefulness of the magic number. If a well- 
known port is allocated by IANA, it should be safe to assume it is  
used for this purpose. If there are malformed packets, for example  
from some older app that doesn't know GUT, they would likely be  
rejected at some point in the processing, because the content would  
not match any protocol state (or checksum calculation) of the inner  
protocol.

- Pasi

On Sep 14, 2009, at 7:16 AM, Jukka MJ Manner wrote:

> implementation that indicates that the concept works quite nicely,  
> at least with the hardware we tried it with (Linux end hosts, some  
> out-of-the-box D-link and Linksys NAT boxes in between). We need to  
> fix and add a few things, then we can release the implementation as  
> open source.
>
> A new version of I-D, draft-manner-tsvwg-gut-00.txt has been  
> successfuly submitted by Jukka Manner and posted to the IETF  
> repository.
>
> <jukka_manner.vcf>

---

From: Jukka Manner <[email-masked]>
Date: Thu, 01 Oct 2009 08:59:58 +0300

Hi Pasi,

Thanks for the comments, some late replies below.

cheers,
Jukka

Pasi Sarolahti wrote:
> encapsulate protocols generally inside UDP in hopes of better middlebox 
> traversal is the right step from the standardization viewpoint (as 
> discussed in earlier BOFs and plenaries, I guess). Putting that question 
> aside, here are some technical thoughts:

Yes, you are right, whether creating some generic UDP tunnelling is a
valid goal would need some wide discussion within the community - I
don't recall what the end resul has been so far, probably against it. My 
quick-and-dirty draft and spec just wanted to trigger some discussion at 
least by making one proposal in that direction. The fact still remains, 
a lot of protocols do not get through NATs or firelwalls, and this harms 
progress.

> 
> I'm a little doubtful about the idea of using a single UDP port for all 
> protocols. The receiver of the UDP datagrams would need to carry out the 
> de-multiplexing and forwarding to different protocol modules and manage 
> the related state, which could as well be done "automatically" by the 
> UDP implementatation, by using different port numbers for each protocol.

For the multplexing, the implementation we have is very simple: at the
receiver, you just get the packet, remove the GUT header, reattach the 
IP header, calculate a possible checksum if the encapsulated protocol 
has one, and give the packet to the IP stack. The stack then handles the
protocols by itself as if it came from the interface directly, the GUT 
implementation does not need to care about the local IP stack processing 
after it has rebuilt the original packet. Our implementation on Linux is 
  only a few hundred lines of code, need to check, but it was quite 
little (without the fragmentation and IP option handling).

> 1) simply allocate the needed range of UDP ports from IANA for different 
> protocols (which might be wasteful), or
> 
> directly to the returned port Y without additional GUT header overhead. 
> In such system it would be easy to add new protocols for 
> configuration file processed by a small application that listens to the 
> queries at a well-known UDP port and responds by returning the port 
> numbers for tunneling the configured protocols.

Of these two, I'd take the latter. It sounds pretty okey to me. You 
could as well send the first encapsulated packet to GUT and have a 
control message saying that subsequent packets should be sent to port P 
from now on.

> 
> In any of the above cases, a strong advise should be given to first try 
> if the native protocol works without UDP encapsulation, before going 
> into UDP tunneling mode.

Naturally this is the way to go. A scheme like GUT could monitor the 
original protocol and if a connection does not seem to materialize, try 
UDP tunneling automagically.

> 
> Other issue: I don't get the usefulness of the magic number. If a 
> well-known port is allocated by IANA, it should be safe to assume it is 
> used for this purpose. If there are malformed packets, for example from 
> some older app that doesn't know GUT, they would likely be rejected at 
> some point in the processing, because the content would not match any 
> protocol state (or checksum calculation) of the inner protocol.

This concept was taken from GIST where we use a magic number for this 
exact purpose, verify that the packet truly (at some level of 
confidence) is a GIST packet. You could live without it, sure, but you 
can run into problems later due to unnecessary packet processing.

>> successfuly submitted by Jukka Manner and posted to the IETF repository.
>>