Subject: UDP encaps for SCTP and SCCP

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Apr 2010 12:57:28 +0300

Hi,

as most of you probably know, there are two different proposals for how to encapsulate SCTP and DCCP inside UDP.

One approach proposes two protocol-specific encapsulation schemes (described in draft-tuexen-sctp-udp-encaps and draft-ietf-dccp-udpencap).

The second approach proposes a generic encapsulation scheme that can be applied to both SCTP and DCCP (draft-manner-tsvwg-gut).

As a community, we do need to come to consensus on which of these two approaches we want to follow when it comes to UDP encapsulation of SCTP and DCCP. I believe it would be very confusing if we were to standardize both approaches.

I'd hence like to ask folks to read the three documents and post their views to the [email-masked] list. I'm personally especially interested in hearing from folks who aren't on the author lists of the documents, but obviously, the authors expert opinions do matter.

Thanks,
Lars

PS: I'm pushing on this topic, because UDP encapsulation is the last remaining work item in the DCCP working group before it can close...

---

From: <[email-masked]>
Date: Thu, 22 Apr 2010 11:50:49 +0100

I looked through all the drafts Lars indicated.

The tuexen draft doesn't discuss checksum issues at all; for SCTP, which has its own checksum, this matters. The dccp udpencap draft does discuss checksum issues, but I suspect having a UDP checksum across an entire payload that has its own stronger checksum (as SCTP does), is not useful. The pseudo-header check is still useful and needed on demux, though. This appears to be an application suitable for UDP-lite, covering the headers and providing the pseudo-header check - not UDP.

http://tools.ietf.org/html/draft-ietf-dccp-udpencap-00#section-3.3

section 3.3 of the draft and its use of UDP as UDP-lite -- despite UDP-lite being given a different protocol number because consensus was that messing with UDP checksum and length fields in this way was not compatible with established UDP implementation use - makes me very very uneasy. (The earlier phelan draft had a hack around using a UDP zero checksum, which is arguably worse.) This draft cannot go forwards. Or it should use UDP-lite. This is a workgroup draft? Seriously? Section 5 of RFC3828 and tsvwg experience indicates why this is a bad idea. Is expedience more important?

The GUT draft and recreating IP packets strikes me as problematic in implementation, just as much as NATs. I'd rather have a simple IP-in-IP-tunnel (or even GRE) and rely on decap at the endpoints...

Does DCCP have any applications using it?

Note that I am NOT expressing a preference for any particular draft here. We should not follow either approach.

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lars Eggert [[email-masked]]
Sent: 22 April 2010 10:57
To: [email-masked]; DCCP working group
Cc: TSV Area
Subject: UDP encaps for SCTP and SCCP

Hi,

Thanks,
Lars

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 22 Apr 2010 14:10:59 -0700

On Apr 22, 2010, at 3:50 AM, <[email-masked]>  
<[email-masked]> wrote:

> section 3.3 of the draft and its use of UDP as UDP-lite -- despite  
> UDP-lite being given a different protocol number because consensus  
> was that messing with UDP checksum and length fields in this way was  
> not compatible with established UDP implementation use - makes me  
> very very uneasy. (The earlier phelan draft had a hack around using  
> a UDP zero checksum, which is arguably worse.) This draft cannot go  
> forwards. Or it should use UDP-lite. This is a workgroup draft?  
> Seriously? Section 5 of RFC3828 and tsvwg experience indicates why  
> this is a bad idea. Is expedience more important?

Some others have made this comment, too, so I think this is something  
that should be changed before the draft moves forward.

None of the drafts in question are final yet, so I think the  
discussion and the subsequent decision should be based on the merits/ 
disadvantages of the overall approaches, rather than the current state  
of the drafts. Although I'm sure the authors will appreciate all  
detailed comments on their drafts as well.

- Pasi

---

From: Jukka Manner <[email-masked]>
Date: Mon, 26 Apr 2010 22:07:26 +0300

Hi Lloyd,

I have to object here. :)

> The GUT draft and recreating IP packets strikes me as problematic in implementation, just as much as NATs. I'd rather have a simple IP-in-IP-tunnel (or even GRE) and rely on decap at the endpoints.…

GUT is not problematic, nor difficult. We have it running on Linux and 
works great. Next we'll put it on BSD (should be just a medium update to 
the code). I'm hoping to release the implementation as open source 
sometime in the future.

Our draft could be much better in explaining the idea clearly. The fact 
that we are "creating ip packets" is due to our implementation being a 
separate piece of code, a separate service on the OS, easily installed. 
The functionality could be as well be integrated into the IP stack, but 
that would be somewhat more challenging.

regards,
Jukka

---

From: <[email-masked]>
Date: Mon, 26 Apr 2010 21:34:14 +0100

> separate piece of code, a separate service on the OS, easily installed.

No. You are "_re_creating IP packets" in that you are not carrying the IP header end-to-end, but are carrying minimal state to recreate an approximation of the original IP header. That makes me nervous. (This is not link header compression.)

You are not encapsulating the IP protocol header, but eviscerating it. You call that "reconstruct the native IP packet" or "rebuild the IP packet".

http://tools.ietf.org/html/draft-manner-tsvwg-gut-01
(can I suggest a spelling checker for the typos?)

The summary benefits you state in section 8 work for a normal UDP tunnel, and with rather less complexity.

On a related note, I spent years dealing with proponents of SCTP, and yet never encountered any actual we-chose-to-use-SCTP end users. So, are there any actual DCCP users out there?

All this effort to save a few bytes tunnelling complex protocols that still won't be used? Pointless.

> that would be somewhat more challenging.

...and won't happen.

L.

> Jukka

Lloyd Wood
[email-masked]

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 08:27:23 +0100

I don't think that counts as a we-chose-to-use-SCTP end user...

SIGTRAN infrastructure in the telephony providers doesn't go through NAT. ergo, SCTP's most popular use doesn't need to go through NAT. And DCCP doesn't need to go through NAT, because no-one uses DCCP... so there's no need to tunnel these over UDP to get through NAT.

actual applications running on an actual end-user computer with a TCP/IP stack, please.

On 26 Apr 2010, at 23:49, Brian F. G. Bidulock wrote:

> L.Wood,
> 
> Hmmm.  SIGTRAN requires SCTP.  SIGTRAN is widely
> deployed and running your phone calls.
> 
> --brian
> 
> [email-masked] wrote:          (Mon, 26 Apr 2010 21:34:14)
> 
> --x-- snip --x--
>> On a related note, I spent years dealing with proponents of
>> SCTP, and yet never encountered any actual
>> we-chose-to-use-SCTP end users. So, are there any actual DCCP
>> users out there?
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

Lloyd Wood
[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 26 Apr 2010 16:49:34 -0600

L.Wood,

--brian

--x-- snip --x--

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Apr 2010 08:47:41 +0100

Hi,

please keep this discussion focused on which approach we should follow for UDP-encapsulating DCCP and SCTP.

I'm happy Lloyd posted his views. I'm hoping other community members will speak up as well. If I were asked to characterize current consensus, I'd probably say "disinterest for either approach." (Which would be fine, but doesn't quite match the earlier feeling I got from the community, i.e., that we do want UDP encaps for these protocols.)

Lars

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 Apr 2010 11:42:41 +0200

Hi,

Okay, I herewith speak up: yes I want to see UDP encapsulation for  
both these protocols
(but right now I'm not sure which one).

Both SCTP and DCCP are useful - if there was no consensus on that,  
ever, these
groups would never have been formed, and the protocols would never have
been developed.

Now, they are not used much (on the Internet involving NATs); at least
DCCP isn't. That's a problem. UDP encapsulation is a way to try to
solve this problem - and saying that we shouldn't do this because the
protocols aren't used is a bit stupid, isn't it?

To repeat this more clearly and bluntly:

tool X isn't working well => noone uses it.
So let's not fix tool X because noone uses it anyway.
Hmmm...

Cheers,
Michael

On Apr 27, 2010, at 9:47 AM, Lars Eggert wrote:

> Hi,
>
> please keep this discussion focused on which approach we should  
> follow for UDP-encapsulating DCCP and SCTP.
>
> I'm happy Lloyd posted his views. I'm hoping other community members  
> will speak up as well. If I were asked to characterize current  
> consensus, I'd probably say "disinterest for either  
> approach." (Which would be fine, but doesn't quite match the earlier  
> feeling I got from the community, i.e., that we do want UDP encaps  
> for these protocols.)
>
> Lars

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Apr 2010 10:55:10 +0100

From my perspective, I would prefer to run a native encapsulation rather than host it in UDP. If one wants a UDP encapsulation, I have no opinion on which of the choices to make, but I would suggest a characteristic you want to have. There is no point having UDP ports *and* SCTP/DCCP ports, and no point in having a UDP checksum *and* an SCTP checksum. I would recommend removing the duplicated functions from the interior protocol and relying on UDP's counterpart, even if it is inferior, as it will be more readily deployed.

On Apr 27, 2010, at 10:42 AM, Michael Welzl wrote:

> Hi,
> 
> Okay, I herewith speak up: yes I want to see UDP encapsulation for both these protocols
> Both SCTP and DCCP are useful - if there was no consensus on that, ever, these

http://www.ipinc.net/IPv4.GIF

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 11:06:05 +0100

"A bit stupid"?

UDP encapsulation of these protocols can already be done. Tunnelling is not new. IP packet, UDP header, IP outer header, you're done.

What is not needed or justified is a 'special' encap which requires documentation, implementation, and then deployment - because lack of deployment of these protocols is already the problem here, and that won't help.

Now, if there were already masses and masses of UDP tunnels of these protocols, with users complaining about MTU issues and the need for efficiencies, then there  just _might_ be a case for it. But if there's no UDP tunnelling of these protocols happening, why create a bespoke solution?

To look at your analogy, you're not fixing tool X. You're saying that tool X would suddenly be magically more useful if tool attachment Y could be added to it; for example, we can't use an odd Torx-variant screwdriver in the dark, so let's add an LED light! But torches are already available, and using a screwdriver in the presence of a separate light source is straightforward and the common case. Having the optional LED light won't sell any more odd Torx-variant screwdrivers.

And there was consensus that the OSI protocols would be useful and a lot of workgroups were formed. So?

(Approach to follow? Neither)

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: Michael Welzl [[email-masked]]
Sent: 27 April 2010 10:42
To: Lars Eggert
Cc: Wood L Dr (Electronic Eng); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: UDP encaps for SCTP and SCCP

Hi,

Cheers,
Michael

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 11:37:40 +0100

Fred,

advocating removing the interior protocol checksum across header and payload (and reconstituting/recomputing it afterwards) violates end-to-endidness and weakens the reliability guarantee. Bad idea. From a checksum perspective, you'd do better saying 'use UDP lite with a minimal check just across its own headers and pseudo-header' to decrease the computational overhead - that should be a fixed value.

Using a UDP (or lite) port to indicate what is being done here with a particular weird encap, as well as the original ports on the interior packet, is something that this approach is stuck with, I think.

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: Fred Baker [[email-masked]]
Sent: 27 April 2010 10:55
To: Lars Eggert
Cc: [email-masked]; [email-masked]; [email-masked]; tsvwg list; Wood L Dr (Electronic Eng); Michael Welzl
Subject: Re: UDP encaps for SCTP and SCCP

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Apr 2010 11:51:58 +0100

willing enough to use UDP-lite. 

BTW, I didn't say "change the encapsulation in some magic box in the network". I should hope that whatever encapculation is used would be used end to end.

My point is "do those functions once".

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 Apr 2010 13:08:16 +0200

Hi,

> "A bit stupid"?

Sorry - I didn't mean to be personal, my point was that this
looks like a self-contradicting (somehow circular) argument.

> UDP encapsulation of these protocols can already be done. Tunnelling  
> is not new. IP packet, UDP header, IP outer header, you're done.
>
> What is not needed or justified is a 'special' encap which requires  
> documentation, implementation, and then deployment - because lack of  
> deployment of these protocols is already the problem here, and that  
> won't help.
>
> Now, if there were already masses and masses of UDP tunnels of these  
> protocols, with users complaining about MTU issues and the need for  
> efficiencies, then there  just _might_ be a case for it. But if  
> there's no UDP tunnelling of these protocols happening, why create a  
> bespoke solution?

ok, I see your point, now - and it makes me wonder why, indeed, we  
don't have
these masses and masses of UDP tunnels, at least for SCTP. But then, not
having an agreement on one particular way of doing that might just be  
a reason.

Let's say that specifying UDP encapsulation increases the chances of,  
e.g., SCTP
usage by just a little bit. What's the big disadvantage that stands  
against doing it?
It doesn't seem like a horribly complex piece of work to me, and what's
the big risk of having it? My view is, at this point we should be  
doing all we
can to get these protocols deployed. Or would you rather go ahead and  
put
them straight into the gallery of deployment failures, together with  
IP multicast,
QoS, etc etc... ?

> To look at your analogy, you're not fixing tool X. You're saying  
> that tool X would suddenly be magically more useful if tool  
> attachment Y could be added to it; for example, we can't use an odd  
> Torx-variant screwdriver in the dark, so let's add an LED light! But  
> torches are already available, and using a screwdriver in the  
> presence of a separate light source is straightforward and the  
> common case. Having the optional LED light won't sell any more odd  
> Torx-variant screwdrivers.

I'm not sure I follow you anymore. How is tunneling over UDP (which  
should
foster deployment of the protocols) the same as adding a pointless  
feature to
SCTP or DCCP?

> lot of workgroups were formed. So?

well, these are not OSI standards, and so there must have been quite  
broad IETF
consensus that these protocols make sense, at some point in time. This  
being
the same standardization body, my concern is about following a zig-zag  
course.
I understand that concensus can change, as the world around us does,
and so going with the facts of today makes sense - but first saying  
"hey, that
seems like a good idea, let's develop this protocol" and then saying  
"hm, noone
uses it, let's not bother trying to make this more practical" seems  
odd and
halfhearted.

Cheers,
Michael

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 12:18:14 +0100

They're already deployment failures.

Straightforward UDP tunnelling (encapsulate IP packet in UDP payload, that's all) is not happening for these protocols.
A custom encapsulation method tailored just to carrying these protocols (in effect, a pointless addition to each protocol) is not justified.

Do you need to create a custom way of UDP tunnelling these protocols just to promote the basic idea of UDP tunnelling? I don't think so.

UDP tunnelling of these protocols can already be done. There's still no demand. Writing a document saying there's a slightly more complicated way to do UDP tunnelling instead of just doing UDP tunnelling won't change that.

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: Michael Welzl [[email-masked]]
Sent: 27 April 2010 12:08
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: UDP encaps for SCTP and SCCP

Hi,

Cheers,
Michael

---

From: Alex Conta <[email-masked]>
Date: Tue, 27 Apr 2010 09:53:46 -0400

IMHO, what should drive the use or no use of UDP is "the need and use of
UDP functons", rather then "the need to make the SCTP and SCCP more
popular because of using a popular transport". Perhaps I am not reading
right the motivation, but I somehow get that frm the thread - sorry...

Which is to say that I agree with Fred's concern 100% about duplications
of functions. 

I would perhaps even go a little further, if the counter-argument is
that with "UDP lite", there is a minimization of duplication, and that
is: 

my concern would be that besides the dupplication, there is some
additional burden in processing a packet that has mutliple header
layers, when passing the packet from one layer to the other. It's not
much, but there is, and can add-up - there are the little things that,
when in larhe numbers, contribute to a considerable load. 
If that can be eliminated, I see it as a plus...

Alex Conta

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, April 27, 2010 6:38 AM
> To: [email-masked]
> Subject: RE: UDP encaps for SCTP and SCCP
> 
> 
> Fred,
> 
> advocating removing the interior protocol checksum across 
> header and payload (and reconstituting/recomputing it 
> afterwards) violates end-to-endidness and weakens the 
> reliability guarantee. Bad idea. From a checksum perspective, 
> you'd do better saying 'use UDP lite with a minimal check 
> just across its own headers and pseudo-header' to decrease 
> the computational overhead - that should be a fixed value.
> 
> Using a UDP (or lite) port to indicate what is being done 
> here with a particular weird encap, as well as the original 
> ports on the interior packet, is something that this approach 
> is stuck with, I think.
> 
> Lloyd Wood
> http://sat-net.com/L.Wood ________________________________________
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> tsvwg list; Wood L Dr (Electronic Eng); Michael Welzl
> From my perspective, I would prefer to run a native 
> encapsulation rather than host it in UDP. If one wants a UDP 
> encapsulation, I have no opinion on which of the choices to 
> make, but I would suggest a characteristic you want to have. 
> There is no point having UDP ports *and* SCTP/DCCP ports, and 
> no point in having a UDP checksum *and* an SCTP checksum. I 
> would recommend removing the duplicated functions from the 
> interior protocol and relying on UDP's counterpart, even if 
> it is inferior, as it will be more readily deployed.
> 
> > both these protocols (but right now I'm not sure which one).
> >
> > ever, these groups would never have been formed, and the protocols 
> > would never have been developed.
> >
> approach." (Which 
> >> would be fine, but doesn't quite match the earlier feeling 
> I got from 
> >> the community, i.e., that we do want UDP encaps for these 
> protocols.)
> >>
> >> Lars
> >
>

---

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 27 Apr 2010 13:46:01 -0400

Hi All,

Well, quite a few issues have been brought up here.  Here are my
thoughts on one of them.

Why not just tunnel it?  "Just tunnel it" means IP header/UDP
header/inner IP header/"real" transport header.  The problem here is in
the addresses in the inner IP header.

In most uses of IPv4 tunneling, the tunnel endpoints either both have
public IP addresses or they both exist in the same private IP address
space.  This provides a coordination of the inner addresses such that
they are meaningful to both the sender and receiver.  In these
conditions, DCCP can be tunneled just like everything else.

However, there are many situations where these conditions don't apply.
One very common situation where these conditions don't exist is when the
client, managed by one organization, is in a private address space
behind a NAT and the server, managed by another organization, is in the
public address space.  This situation, and the several variants that are
possible, are more the target of the DCCP encap draft.

In the private-client-nat-public-server configuration, the client will
initially set the outer and inner source addresses to private addresses
(possibly the same address for both, possibly different).  The NAT will
change the outer source address to a public address, but not the inner.
When the inner packet is extracted at the server, the inner source
address will be meaningless (and leaks information that is normally held
private).  On the return path, it'll be the destination address that's
meaningless.

You can imagine many ways that the client can set inner addresses to
values that would mean something to the server, but it's difficult to
see how the server could set the inner addresses meaningfully without
having the client's private address leaked to it (define a "neutral"
address space?).

But if you do solve the inner address meaning problem, what have you
gained?  Nothing, I believe.  The inner addresses are fundamentally
useless.  So why carry useless fields?  Make it IP header/UDP
header/transport header.  This is the approach all three current drafts
take.

Tom P.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alex Conta
> Sent: Tuesday, April 27, 2010 9:54 AM
> To: [email-masked]; [email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 27 Apr 2010 20:08:20 +0200

Hi Fred,

I can understand in general your point that things should not be done multiple times.
So you argue not to have a UDP and SCTP/DCCP checksum and not to duplicate the port
numbers. I would like to address these suggestions individually:

1. Checksum
   SCTP uses a 32-bit CRC32c which is much stronger than the 16 bit UDP checksum.
   Therefore only using the UDP checksum doesn't make sense.
   In the first version of the SCTP/UDP encapsulation implementation of
   FreeBSD/Mac OS X I just did not use the UDP checksum but relied only on the
   SCTP one. But what do I gain? Most NICs do UDP checksum offloading, so I
   just enabled it. For SCTP/UDP/IPv6 I was required to so anyway.
   For DCCP this is different. They use the same checksum as UDP, but allow
   for partial coverage. So maybe UDP-light might be what they prefer. Not sure.

2. Port numbers
   The basic question is: Why do you want to encapsulate SCTP or DCCP in UDP?
   I see two reasons:
   (a) Being able to communicate through NATs which do not support SCTP or DCCP.
   (b) Being able to implement SCTP or DCCP on hosts which do not allow
       loading kernel modules, replace the kernel or even use raw sockets.
       The iPhone is one example...
   If you want to address (b), you can use UDP port numbers also for DCCP and
   SCTP port numbers. But if you want to address (a) the situation is different
   for SCTP. This is because SCTP support multihoming and each SCTP end-point
   has only a single port number. So the NAT boxes on different paths might
   modify the UDP port numbers in an uncoordinated way, but SCTP still expects
   a unique SCTP port number. Therefore, at least for SCTP and the usage szenario
   (a), requires both port numbers: the UDP ones and the SCTP ones.

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 27 Apr 2010 20:13:14 +0200

On Apr 26, 2010, at 9:07 PM, Jukka Manner wrote:

> GUT is not problematic, nor difficult. We have it running on Linux and works great. Next we'll put it on BSD (should be just a medium update to the code). I'm hoping to release the implementation as open source sometime in the future.
Hi Jukka,

please note that the encapsulation/decapsulation part for SCTP is simple. However,
if you want to do the encapsulation because you want to traverse NAT which are
not supporting SCTP, you also must avoid all transport addresses inside the SCTP
layer. This needs to be described somewhere and is specific to SCTP. It might
be able to generalize it to transports which support multihoming.

Also, if you cover the handling of ICMP messages, you must provide some protocol
specific packet validation, I think. For example, in case of SCTP, you need to
validate the verification tag before processing the packet inside the SCTP stack.

Best regards
Michael
> 
> Our draft could be much better in explaining the idea clearly. The fact that we are "creating ip packets" is due to our implementation being a separate piece of code, a separate service on the OS, easily installed. The functionality could be as well be integrated into the IP stack, but that would be somewhat more challenging.
> 
> regards,
> Jukka
>

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 27 Apr 2010 20:15:34 +0200

>> that would be somewhat more challenging.
The SCTP/UDP encapsulation is implemented in FreeBSD and part of the SCTP kernel
implementation for Mac OS X.

Best regards
Michael

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 19:18:21 +0100

But encapsulation methods intended for endhosts wind up in middleboxes.

Look at Cisco's RBSCP and WAAS (and the recently discontinued NCE), which already rewrite between SCTP and TCP checksums.

Any new encap method blessed by the IETF must be considered for worst-case middlebox use - where rewriting stronger with weaker checksums and breaking end-to-end integrity will happen. It will pop up in middleboxes.

This is why I prefer simple UDP tunnels.

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: 27 April 2010 11:52
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: UDP encaps for SCTP and SCCP

On Apr 27, 2010, at 11:37 AM, <[email-masked]> wrote:

> Cc: [email-masked]; [email-masked]; [email-masked]; tsvwg 
> list; Wood L Dr (Electronic Eng); Michael Welzl
>> Now, they are not used much (on the Internet involving NATs); at 
>> least DCCP isn't. That's a problem. UDP encapsulation is a way to try 
>> to solve this problem - and saying that we shouldn't do this because 
>> the protocols aren't used is a bit stupid, isn't it?
>> 
>>> consensus, I'd probably say "disinterest for either approach." 
>>> (Which would be fine, but doesn't quite match the earlier feeling I 
>>> got from the community, i.e., that we do want UDP encaps for these 
>>> protocols.)
>>> 
>>> Lars
>> 
>

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 19:26:22 +0100

That's hardly integrated into a shipping IP stack.

FreeBSD may be an SCTP reference implementation, but that's not significant deployment.

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: 27 April 2010 19:16
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: UDP encaps for SCTP and SCCP

On Apr 26, 2010, at 10:34 PM, <[email-masked]> <[email-masked]> wrote:

>> GUT is not problematic, nor difficult. We have it running on Linux 
>> and works great. Next we'll put it on BSD (should be just a medium 
>> update to the code). I'm hoping to release the implementation as open 
>> source sometime in the future.
>> 
>> Our draft could be much better in explaining the idea clearly. The 
>> fact that we are "creating ip packets" is due to our implementation 
>> being a separate piece of code, a separate service on the OS, easily installed.
> 
> No. You are "_re_creating IP packets" in that you are not carrying the 
> IP header end-to-end, but are carrying minimal state to recreate an 
> approximation of the original IP header. That makes me nervous. (This 
> is not link header compression.)
> 
>> The functionality could be as well be integrated into the IP stack, 
>> but that would be somewhat more challenging.
> 
> ...and won't happen.
The SCTP/UDP encapsulation is implemented in FreeBSD and part of the SCTP kernel implementation for Mac OS X.

Best regards
Michael

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 21:43:55 +0100

Why not craft the inner packet with inner src and destination to a local loopback address (127.0.0.1) before sticking it in the UDP header?

Preserves layering, preserves multihoming, avoids public/private address space concerns, prevents similar tunnelling by middleboxes.

Of course, there's tracking the real src and dst in the added/discarded UDP header, and associating those with the decapped inner packet -- tch, implementation details...

L.

-----Original Message-----
From: Phelan, Tom [mailto:[email-masked]] 
Sent: 27 April 2010 18:46
To: Alex Conta; Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it?

Hi All,

Well, quite a few issues have been brought up here.  Here are my thoughts on one of them.

Why not just tunnel it?  "Just tunnel it" means IP header/UDP header/inner IP header/"real" transport header.  The problem here is in the addresses in the inner IP header.

In most uses of IPv4 tunneling, the tunnel endpoints either both have public IP addresses or they both exist in the same private IP address space.  This provides a coordination of the inner addresses such that they are meaningful to both the sender and receiver.  In these conditions, DCCP can be tunneled just like everything else.

However, there are many situations where these conditions don't apply.
One very common situation where these conditions don't exist is when the client, managed by one organization, is in a private address space behind a NAT and the server, managed by another organization, is in the public address space.  This situation, and the several variants that are possible, are more the target of the DCCP encap draft.

In the private-client-nat-public-server configuration, the client will initially set the outer and inner source addresses to private addresses (possibly the same address for both, possibly different).  The NAT will change the outer source address to a public address, but not the inner.
When the inner packet is extracted at the server, the inner source address will be meaningless (and leaks information that is normally held private).  On the return path, it'll be the destination address that's meaningless.

You can imagine many ways that the client can set inner addresses to values that would mean something to the server, but it's difficult to see how the server could set the inner addresses meaningfully without having the client's private address leaked to it (define a "neutral"
address space?).

But if you do solve the inner address meaning problem, what have you gained?  Nothing, I believe.  The inner addresses are fundamentally useless.  So why carry useless fields?  Make it IP header/UDP header/transport header.  This is the approach all three current drafts take.

Tom P.

> > advocating removing the interior protocol checksum across header and 
> > payload (and reconstituting/recomputing it
> > afterwards) violates end-to-endidness and weakens the reliability 
> > guarantee. Bad idea. From a checksum perspective, you'd do better 
> > saying 'use UDP lite with a minimal check just across its own 
> > headers and pseudo-header' to decrease the computational overhead - 
> > that should be a fixed value.
> >
> > Using a UDP (or lite) port to indicate what is being done here with 
> > a particular weird encap, as well as the original ports on the 
> > interior packet, is something that this approach is stuck with, I 
> > think.
> >
> > Lloyd Wood
> > From my perspective, I would prefer to run a native encapsulation 
> > rather than host it in UDP. If one wants a UDP encapsulation, I have 
> > no opinion on which of the choices to make, but I would suggest a 
> > characteristic you want to have.
> > There is no point having UDP ports *and* SCTP/DCCP ports, and no 
> > point in having a UDP checksum *and* an SCTP checksum. I would 
> > recommend removing the duplicated functions from the interior 
> > protocol and relying on UDP's counterpart, even if it is inferior, 
> > as it will be more readily deployed.
> >

---

From: Alex Conta <[email-masked]>
Date: Wed, 28 Apr 2010 02:20:16 -0400

Tom P.

>From a quick glance to your message, it is not clear why one would need
or want 
IP tunneling from end-node to end-node in this case - sorry if I missed
the explanation. 
Both Inner and Outer IP headers seem to have the same IP addresses, if I
get it right.

Is perhaps the role given to IP tunneling just to have "some" header as
a separator between the UDP header and the SCTP header?

On using UDP just to encapsulate a transport packet, While thinking out
loudly, I will go back to the basics. UDP has three functions - (1)
identify the end points of 
Communications - port numbers, (2) ensure end points and data integrity
- checksum, and (3) define/carry an atomic datagram - datagram length.

The duplication of functions with SCTP has been recognized already as a
fact.

UDP is being given the role, or function of bypassing NATs, who seem to
be agnostic of SCTP/DDCP - this has nothing to do with the basic
functions of UDP, but rather with the shortcomings of NATs.... 

I imagine the IPv6 guys would have something to say about this...

I wonder if any of the two drafts is going to be on the Standards track.

Regards,
Alex Conta

> Sent: Tuesday, April 27, 2010 1:46 PM
> To: Alex Conta; [email-masked]; [email-masked]
> header/inner IP header/"real" transport header.  The problem 
> here is in the addresses in the inner IP header.
> 
> In most uses of IPv4 tunneling, the tunnel endpoints either
> both have public IP addresses or they both exist in the same 
> private IP address space.  This provides a coordination of 
> the inner addresses such that they are meaningful to both the 
> sender and receiver.  In these conditions, DCCP can be 
> tunneled just like everything else.
> 
> However, there are many situations where these conditions
> don't apply. One very common situation where these conditions 
> don't exist is when the client, managed by one organization, 
> is in a private address space behind a NAT and the server, 
> managed by another organization, is in the public address 
> space.  This situation, and the several variants that are 
> In the private-client-nat-public-server configuration, the
> client will initially set the outer and inner source 
> addresses to private addresses (possibly the same address for 
> both, possibly different).  The NAT will change the outer 
> source address to a public address, but not the inner. When 
> the inner packet is extracted at the server, the inner source 
> address will be meaningless (and leaks information that is 
> normally held private).  On the return path, it'll be the 
> destination address that's meaningless.
> 
> You can imagine many ways that the client can set inner
> addresses to values that would mean something to the server, 
> but it's difficult to see how the server could set the inner 
> addresses meaningfully without having the client's private 
> address leaked to it (define a "neutral" address space?).
> 
> But if you do solve the inner address meaning problem, what
> have you gained?  Nothing, I believe.  The inner addresses 
> are fundamentally useless.  So why carry useless fields?  
> Make it IP header/UDP header/transport header.  This is the 
> approach all three current drafts take.
> 
> Tom P.
> 
> 
> [mailto:[email-masked]] On
> > Behalf Of Alex Conta
> > IMHO, what should drive the use or no use of UDP is "the
> need and use
> of
> header and
> here with
> > > characteristic you want to have. There is no point having 
> UDP ports
> > > *and* SCTP/DCCP ports, and no point in having a UDP
> checksum *and*
> > > an SCTP checksum. I would recommend removing the duplicated
> > > functions from the interior protocol and relying on UDP's 
> > > counterpart, even if it is inferior, as it will be more readily 
> > > deployed.
> > >
> > > > So let's not fix tool X because noone uses it anyway. Hmmm...
> > > >
> > > > Cheers,
> > > > Michael
> > > >
> > > >

---

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 28 Apr 2010 09:36:40 -0400

Hi Lloyd,

See inline...

Tom P.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 27, 2010 4:44 PM
> To: Phelan, Tom; [email-masked]; [email-masked]
> Why not craft the inner packet with inner src and destination to a
local
> loopback address (127.0.0.1) before sticking it in the UDP header?
> 
[Tom P.] Well, then you aren't "just tunneling it", are you?

> Preserves layering, preserves multihoming, avoids public/private
address
> space concerns, prevents similar tunnelling by middleboxes.
> 
> Of course, there's tracking the real src and dst in the
added/discarded
> UDP header, and associating those with the decapped inner packet --
tch,
> implementation details...
> 
[Tom P.] I think that after examining these implementation details that
it's better to eliminate the inner addresses -- why carry something that
has no real function?

> Well, quite a few issues have been brought up here.  Here are my
thoughts
> on one of them.
header/inner
> IP header/"real" transport header.  The problem here is in the
addresses
> in the inner IP header.
they
> are meaningful to both the sender and receiver.  In these conditions,
DCCP
> can be tunneled just like everything else.
> 
behind
> a NAT and the server, managed by another organization, is in the
public
> address space.  This situation, and the several variants that are
address
> will be meaningless (and leaks information that is normally held
private).
> On the return path, it'll be the destination address that's
meaningless.
> values that would mean something to the server, but it's difficult to
see
> how the server could set the inner addresses meaningfully without
having
> the client's private address leaked to it (define a "neutral"
> address space?).
> 
> > IMHO, what should drive the use or no use of UDP is "the need and
use

---

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 28 Apr 2010 09:40:39 -0400

Hi Alex,

I'm having a little trouble understanding your points below.  It seems
to me that you're thinking that the purpose of these drafts is UDP
tunneling/encapsulation of DCCP and SCTP.  That's the mechanism, not the
purpose.  The purpose is to allow these transports to pass through NAT
devices that don't understand the transport protocols.

Sorry if I'm being dense here, but that's what I get from reading your
message...

Tom P.

> From: Alex Conta [mailto:[email-masked]]
> Sent: Wednesday, April 28, 2010 2:20 AM
> To: Phelan, Tom; [email-masked]; [email-masked]
reliability
> > > > Cc: [email-masked]; [email-masked]; [email-masked];
tsvwg
> > > > From my perspective, I would prefer to run a native
encapsulation

---

From: <[email-masked]>
Date: Wed, 28 Apr 2010 14:44:58 +0100

Why carry something that has no real function?

Because it avoids messing up the inner packet's existing checksums, structure, and pseudo-header checks.

recursive loopback tunnelling is still tunnelling.

(Plus, there's a whole host of loopback addresses in the range, so associating a unique loopback address with each different connection and state becomes very straightforward...)

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: Phelan, Tom [[email-masked]]
Sent: 28 April 2010 14:36
To: Wood L Dr (Electronic Eng); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it?

Hi Lloyd,

See inline...

Tom P.

> Why not craft the inner packet with inner src and destination to a local

> Preserves layering, preserves multihoming, avoids public/private address
> Of course, there's tracking the real src and dst in the added/discarded
> UDP header, and associating those with the decapped inner packet -- tch,

thoughts
header/inner
addresses
they
DCCP
behind
public
address
private).
meaningless.
see
having
use

---

From: Alex Conta <[email-masked]>
Date: Wed, 28 Apr 2010 12:43:21 -0400

Hi Tom P.

The premise that there is a value for the application in using SCTP
and/or DDCP, even when encapsulated in UDP is essential - without that
premise, using UDP instead of SCTP or DDCP makes more sense.

Putting my concerns aside, I will try to be helpful to the thread by
going back to the original question that started it. 

The 3 drafts seem to me, that while trying to basically resolve the same
problem, each of them 
provides some differentiation with its own merits, which indicates the
preferences that implementers 
may have.

In my opinion, the 3 mechanisms could be each standard on their own - a
precedent exist, if one looks at IP tunneling.

Having a subset of DDCP, to use with UDP has its merits, it has value
IMO in becoming a standard.

The UDP encapsulation of SCTP, just inserting a UDP header, and using
the same IP header, can be extended with encapsulating DDCP, and become
a "simple UDP encapsulation".

GUT, as "generic UDP encapsulation", provides some additional
functionality to "simple UDP encapsulation", and that has a value of its
own.

Regards,
Alex Conta

> Sent: Wednesday, April 28, 2010 9:41 AM
> I'm having a little trouble understanding your points below.
> It seems to me that you're thinking that the purpose of these 
> drafts is UDP tunneling/encapsulation of DCCP and SCTP.  
> That's the mechanism, not the purpose.  The purpose is to 
> allow these transports to pass through NAT devices that don't 
> understand the transport protocols.
> 
> Sorry if I'm being dense here, but that's what I get from
> reading your message...
> 
> Tom P.
> 
> > Both Inner and Outer IP headers seem to have the same IP
> addresses, if
> I
> > get it right.
> > 
> > identify the end points of Communications - port numbers, 
> (2) ensure
> > end points and data
> integrity
> > The duplication of functions with SCTP has been recognized
> already as
> a
> > fact.
> > 
> > > header/inner IP header/"real" transport header.  The 
> problem here is
> > > in the addresses in the inner IP header.
> > >
> > > In most uses of IPv4 tunneling, the tunnel endpoints either both
> > > have public IP addresses or they both exist in the same 
> private IP
> > > address space.  This provides a coordination of the inner
> addresses
> > > such that they are meaningful to both the sender and
> receiver.  In
> > > these conditions, DCCP can be tunneled just like everything else.
> > >
> > > However, there are many situations where these conditions don't
> > > apply. One very common situation where these conditions 
> don't exist
> > > is when the client, managed by one organization, is in a private
> > > address space behind a NAT and the server, managed by another 
> > > organization, is in the public address space.  This 
> situation, and
> > > the several variants that are possible, are more the
> target of the
> > > DCCP encap draft.
> > >
> > > In the private-client-nat-public-server configuration, the client
> > > will initially set the outer and inner source addresses 
> to private
> > > addresses (possibly the same address for both, possibly
> different).
> > > The NAT will change the outer source address to a public address,
> > > but not the inner. When the inner packet is extracted at 
> the server,
> > > the inner source address will be meaningless (and leaks
> information
> > > that is normally held private).  On the return path, it'll be the 
> addresses to
> > > values that would mean something to the server, but it's
> difficult
> > > to see how the server could set the inner addresses meaningfully
> > > without having the client's private address leaked to it 
> (define a
> > > "neutral" address space?).
> > >
> > > header/transport header.  This is the approach all three current 
> > > drafts take.
> > >
> > > Tom P.
> > >
> > >
> > > > > interior packet, is something that this approach is
> stuck with,
> I
> > > > > think.
> > > > >
> > > > > Lloyd Wood
> > > > > no opinion on which of the choices to make, but I
> would suggest
> a