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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [tphelan@xxxxxxxxxxxx]
Sent: 28 April 2010 14:36
To: Wood L Dr (Electronic Eng); aconta@xxxxxxxxxxxxx; fred@xxxxxxxxx
Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it?

Hi Lloyd,

See inline...

Tom P.

> -----Original Message-----
> From: L.Wood@xxxxxxxxxxxx [mailto:L.Wood@xxxxxxxxxxxx]
> Sent: Tuesday, April 27, 2010 4:44 PM
> To: Phelan, Tom; aconta@xxxxxxxxxxxxx; fred@xxxxxxxxx
> Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
> Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it?
>
> 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?

> L.
>
> -----Original Message-----
> From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx]
> Sent: 27 April 2010 18:46
> To: Alex Conta; Wood L Dr (Electronic Eng); fred@xxxxxxxxx
> Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
> 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: tsv-area-bounces@xxxxxxxx [mailto:tsv-area-bounces@xxxxxxxx]
On
> > Behalf Of Alex Conta
> > Sent: Tuesday, April 27, 2010 9:54 AM
> > To: L.Wood@xxxxxxxxxxxx; fred@xxxxxxxxx
> > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
> > 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: tsv-area-bounces@xxxxxxxx
> > > [mailto:tsv-area-bounces@xxxxxxxx] On Behalf Of
L.Wood@xxxxxxxxxxxx
> > > Sent: Tuesday, April 27, 2010 6:38 AM
> > > To: fred@xxxxxxxxx
> > > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
> > > 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 [fred@xxxxxxxxx]
> > > Sent: 27 April 2010 10:55
> > > To: Lars Eggert
> > > Cc: bidulock@xxxxxxxxxxx; dccp@xxxxxxxx; tsv-area@xxxxxxxx; 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
> >
> >



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux