Subject: Generic UDP Tunneling (GUT) v2 (-01)

From: Jukka Manner <[email-masked]>
Date: Mon, 08 Mar 2010 22:17:10 +0200

Hi,

We have updated the so-called GUT draft, rewritten some of it based on 
Bob Briscoe's feedback and our own findings while working on the 
implementation.

http://tools.ietf.org/html/draft-manner-tsvwg-gut-01

One note: the text talks about "process" and seems to indicate that GUT 
is a separate entity. That is because our current implementation is a 
separate GUT process. It could as well be integrated with the network 
stack. One benefit of the process-approach is that by installing a 
separate binary, a host gains GUT support, instead of waiting for the OS 
network stack to include the functionality sometime, some year (maybe 
never). GUT also supports a proxy mode, so you don't even need GUT code 
on an end host.

regards,
Jukka

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 21 Mar 2010 00:52:29 +0000

Jukka,

Looking good.

IHL
---
Is the new IHL field really necessary? Surely the IHL after the UDP & 
GUT shims are removed will always be 3 less than before?

If it is necessary, it needs to say what it intends to do with the 
IHL for IPv6.

WHy do you say
"  The IP header length obviously gives the length of the whole GUT
    packet including the encapsulated transport protocol packet."?
That's not obvious to me at all. IHL normally doesn't include the 
payload, and later you say this number gets swapped into the IP 
header's IHL field.

Checksum Coverage
-----------------
On chatting with Gorry last night, I've realised you're right not to 
have used my random thoughts on trying to pack 'Next Header' and 
'Checksum Coverage' into the UDP Length field. If the UDP header 
doesn't have the semantics of a standard UDP header, there's bound ot 
be middleboxes out there that throw a wobbly. Given GUT is trying to 
get through all these wonderful boxes, it needs to look like straight 
UDP as much as possible.

There is still the issue of GUT's checksum coverage though. It's 
certain a middlebox will not fully validate the checksum. It will 
just incrementally update it if it changes port numbers etc. So we 
ought to consider limiting GUT checksum coverage to just the octets 
outside the native transport header. This is purely for efficiency - 
to avoid running the whole payload through the checksum calculation 
twice - with all the memory shifts that will entail. The IHL header 
can't double up as a checksum coverage field, because there may be 
next headers that aren't IP options before the native transport header.

Next Headers
------------
A further issue to do with next headers: The application (or 
something) has to be able to determine whether some next headers are 
outside GUT, and which ones are inside. Because some will want to be 
visible hop by hop. That's a tough question: for both GUT ends.

Dual NAT scenario
-----------------
Ought to show it works with NATs both ends (and multilayer) in the 
next version.

Nits
-----
"  it MUST store the 5-tuple or 3-tuple [...] of the encapsulated IP 
packet flow.  "
Later you say it doesn't have to if the two source ports are the 
same. So you shouldn't say MUST. perhaps say "MUST ... if the ports 
are different."

"GUT SHOULD drop the packet silently."
The ICMP port unreachable error message is intended for this case. 
There must be some suitable wording agreed already somewhere else in 
the IETF for saying this should be sent, but it opens a vulnerability 
to port scanning, DDoS etc.

Bob

At 20:17 08/03/2010, Jukka Manner wrote:
>Hi,
>
>We have updated the so-called GUT draft, rewritten some of it based 
>on Bob Briscoe's feedback and our own findings while working on the 
>implementation.
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Jukka Manner <[email-masked]>
Date: Mon, 22 Mar 2010 06:05:57 -0700

Hi Bob,

> GUT shims are removed will always be 3 less than before?

IHL = 5 if there are no IPv4 options, and > 5 if there are. Now if we 
want to "hide" (=encapsulate) an IPv4 option in GUT, the outer IPv4 
header will have IHL = 5 and after UDP+GUT we have the actual IPv4 
option followed by the actual protocol payload. We have to carry the 
information in the GUT packet about whether the payload inside UDP+GUT 
includes an IPv4 option. Otherwise the receiver will not be able to 
build the IP packet properly, will put in IHL = 5 and parsing the packet 
will fail since the network stack will not know there is an IPv4 option 
bw. the IP header and the payload protocol.

>
> If it is necessary, it needs to say what it intends to do with the IHL
> for IPv6.

v6 has the next header concept, IHL is not used. The text should say 
that IHL is only needed for IPv4.

> payload, and later you say this number gets swapped into the IP header's
> IHL field.

Typo...:) Should say "total length field in the IP header" (not IHL).

> 'Checksum Coverage' into the UDP Length field. If the UDP header doesn't
> have the semantics of a standard UDP header, there's bound ot be
> middleboxes out there that throw a wobbly. Given GUT is trying to get
> through all these wonderful boxes, it needs to look like straight UDP as
> much as possible.

Right. :)

>
> There is still the issue of GUT's checksum coverage though. It's certain
> a middlebox will not fully validate the checksum. It will just
> incrementally update it if it changes port numbers etc. So we ought to
> consider limiting GUT checksum coverage to just the octets outside the
> native transport header. This is purely for efficiency - to avoid
> running the whole payload through the checksum calculation twice - with
> all the memory shifts that will entail. The IHL header can't double up
> as a checksum coverage field, because there may be next headers that
> aren't IP options before the native transport header.

Sounds fine to me.

>
> Next Headers
> ------------
> A further issue to do with next headers: The application (or something)
> has to be able to determine whether some next headers are outside GUT,
> and which ones are inside. Because some will want to be visible hop by
> hop. That's a tough question: for both GUT ends.

Since GUT is not visible to the IP routers and middleboxes, GUT could 
introduce its own numbering space that is fundamentally the same as the 
standard IPv4 protocol type/ v6 next header but add some new numbers 
that would be GUT specific. The GUT protocol type could even be longer 
than 8 bits, or we could have some extra flag in there to introduce 
additional payloads/next headers. Should be rather simple.

>
> Dual NAT scenario
> -----------------
> Ought to show it works with NATs both ends (and multilayer) in the next
> version.

Sure.

> Later you say it doesn't have to if the two source ports are the same.
> So you shouldn't say MUST. perhaps say "MUST ... if the ports are
> different."

right.

> The ICMP port unreachable error message is intended for this case. There
> must be some suitable wording agreed already somewhere else in the IETF
> for saying this should be sent, but it opens a vulnerability to port
> scanning, DDoS etc.

right, too. will check.

thanks a lot.

Jukka

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 22 Mar 2010 17:59:52 +0000

Jukka,

At 13:05 22/03/2010, Jukka Manner wrote:
>IHL = 5 if there are no IPv4 options, and > 5 if there are. Now if 
>we want to "hide" (=encapsulate) an IPv4 option in GUT, the outer 
>IPv4 header will have IHL = 5 and after UDP+GUT we have the actual 
>IPv4 option followed by the actual protocol payload. We have to 
>carry the information in the GUT packet about whether the payload 
>inside UDP+GUT includes an IPv4 option. Otherwise the receiver will 
>not be able to build the IP packet properly, will put in IHL = 5 and 
>parsing the packet will fail since the network stack will not know 
>there is an IPv4 option bw. the IP header and the payload protocol.

Duh. Ignore me on this point - brain fart.

>that IHL is only needed for IPv4.

Yup, text needs adding.

>Typo...:) Should say "total length field in the IP header" (not IHL).

Surely the typo is:

Original:
" The IP header length obviously gives the length of the whole GUT
packet including the encapsulated transport protocol packet."

Suggested:
" The GUT IP header length gives the length of any encapsulated IPv4 
Options, but not including the encapsulated native transport protocol packet."

>>aren't IP options before the native transport header.

The para identifies a problem. Presumably that's not fine ;)

Thinking more about this: Would it be possible to have a Shim Length 
field, instead of calling it IHL? It would give the size of headers 
after the GUT header and before the Native Transport.

Then, could this be used for multiple purposes:
- IPv4: To calculate the IHL
- IPv6 & IPv4: GUT checksum coverage

The only way this might break is if strawman headers that are not IP 
Options are added before the Native transport header. But (arguing 
against myself) wouldn't these strawman headers actually be defined 
as the Native Protocol headers? Then if someone wants to layer 
multiple transport headers, the layers start at the first Native 
Transport header, not outside it.

>Since GUT is not visible to the IP routers and middleboxes, GUT 
>could introduce its own numbering space that is fundamentally the 
>same as the standard IPv4 protocol type/ v6 next header but add some 
>new numbers that would be GUT specific. The GUT protocol type could 
>even be longer than 8 bits, or we could have some extra flag in 
>there to introduce additional payloads/next headers. Should be rather simple.

Yup.

Cheers

Bob

---

From: Jukka Manner <[email-masked]>
Date: Tue, 23 Mar 2010 01:15:20 +0200

Hi, [cut the parts we agree]

> after the GUT header and before the Native Transport.

JM: Sure.

> - IPv6 & IPv4: GUT checksum coverage

JM: So you mean checksum would cover everything up to the encapsulated 
IP payload? Sounds fine to me.

> against myself) wouldn't these strawman headers actually be defined as
> the Native Protocol headers? Then if someone wants to layer multiple
> transport headers, the layers start at the first Native Transport
> header, not outside it.

JM: So for example, you could have:

[IP][UDP][GUT][IP opt][XYZ][TCP][payload] where

XYZ is some extension that is not an IP option but something else, to 
give some new functionality to the native protocol. Checksum coverage 
would be up to and including XYZ. For the receiving GUT to be able to 
parse through that stack, it would need a way to figure out where the IP 
option ends and XYZ starts.

cheers,
Jukka

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 23 Mar 2010 23:39:52 +0000

Jukka,

Nearly agreeing - inline...

At 23:15 22/03/2010, Jukka Manner wrote:
>JM: So you mean checksum would cover everything up to the 
>encapsulated IP payload? Sounds fine to me.
>
>>
>XYZ is some extension that is not an IP option but something else, 
>to give some new functionality to the native protocol. Checksum 
>coverage would be up to and including XYZ. For the receiving GUT to 
>be able to parse through that stack, it would need a way to figure 
>out where the IP option ends and XYZ starts.

Yes, this is what I meant, but I was pointing out this only works for 
checksum coverage, not for calculating the IHL.

So I was thinking "Is there a good scenario where anything like XYZ 
will exist?" If not, we should just treat XYZ as the Native Protocol, 
not TCP (in your example).

Bob

---

From: Jukka Manner <[email-masked]>
Date: Tue, 23 Mar 2010 20:01:29 -0700

Hi Bob,

[cut the excess parts]

On 03/23/2010 04:39 PM, Bob Briscoe wrote:
>> parse through that stack, it would need a way to figure out where the
>> IP option ends and XYZ starts.
>
> So I was thinking "Is there a good scenario where anything like XYZ will
> exist?" If not, we should just treat XYZ as the Native Protocol, not TCP
> (in your example).

Well, within GUT we haven't thought about explicit XYZ-extensions beyond 
the 4-byte GUT header itself. Yet, since GUT is it's own encapsulation, 
GUT could have internal extension headers (=XYZ) for some yet unknown 
purpose (maybe carry extra information related to the encapsulated 
protocol?), or XYZ could be a new experimental IP option, for example.

Currently I don't what XYZ could be.

cheers,
Jukka