Re: Generic UDP tunneling (draft-manner-tsvwg-gut-00)
Bob Briscoe <rbriscoe <at> jungle.bt.co.uk>
2010-02-03 12:13:37 GMT
Jukka,
I'm about to send a review of your (& Nuutti's) GUT draft. But some
of my review relates to Pasi's points in the old thread below. So
I'll rekindle it, inline...
At 05:59 01/10/2009, Jukka Manner wrote:
>Hi Pasi,
>
>Thanks for the comments, some late replies below.
>
>cheers,
>Jukka
>
>Pasi Sarolahti wrote:
>>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:
>
>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.
There are two reasons new protocols can't be deployed:
i) deliberate: the above tussle where "new = potentially dangerous"
ii) accidental: lazy middlebox designs that don't take account of evolvability
GUT allows (i) to still play out as before.
But at least it aims to remove (ii).
You might want to say this in the draft.
>>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.
Pasi, what's the real problem you see?
For me, the problem is that we are having to create a whole sub-layer
just to get back to where we were before badly designed NATs were
deployed. But if that's the best we can do, we need to grasp the nettle.
>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).
>
>>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.
>
>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.
I prefer something like the GUT approach to both of these. The choice
is between:
1) wasting port numbers
2) wasting round trop times
GUT) wasting header bandwidth
For me, avoiding RTTs is the most important thing for a datagram
service. It needs to get started with minimum delay. The first
datagram may be the only one, but fast start is still important even
if it might be supporting connection-oriented services above it like
DCCP or SCTP. Short flows are where all the value is on the Internet,
so we don't need extra RTTs to get started. Then we might as well
have used ATM.
Building in an unnecessary extra RTT delay should only be
contemplated if no other way will ever be possible.
>>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.
An implementation could try both native & GUT in parallel (perhaps
heuristically if it has found that every time it doesn't use GUT for
certain protocols, it gets no response - i.e. the blackhole is
probably its own NAT).
>>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.
I also would prefer GUT without the magic number. See my full review for why.
Cheers
Bob
>>- Pasi
>>
>>On Sep 14, 2009, at 7:16 AM, Jukka MJ Manner wrote:
>>
>>>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.
>
________________________________________________________________
Bob Briscoe, BT Innovate & Design
Maybe IANA can give some examples.
RSS Feed