Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it?

From: Alex Conta <[email-masked]>
Date: Wed, 28 Apr 2010 06:20:42 -0000

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

> -----Original Message-----
> From: Phelan, Tom [mailto:[email-masked]]
> Sent: Tuesday, April 27, 2010 1:46 PM
> To: Alex Conta; [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 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.
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] On
> > Behalf Of Alex Conta
> > Sent: Tuesday, April 27, 2010 9:54 AM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: UDP encaps for SCTP and SCCP
> > 
> > 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]
> > > Cc: [email-masked]; [email-masked]; [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 ________________________________________
> > > 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 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 (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
> > > >
> > >
> > http://www.ipinc.net/IPv4.GIF
> > 
> > 
> 
>

---

From: Alex Conta <[email-masked]>
Date: Wed, 28 Apr 2010 16:44:00 -0000

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
> 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]
> > 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.
> > 
> > > 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.
> > >
> > > 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?).
> > >
> > > 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.
> > >
> > >
> > > > > 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