[Spread-users] Tunnels

Mark Anacker manacker at lizardtech.com
Wed Jan 9 12:20:33 EST 2002

Spread's default mechanism (and secure-spread isn't relevant right now) is
to use plaintext UDP packets.  That's fine on the local segments, but not
the Internet.  What your (and all other) VPN's is doing is creating a second
IP layer *on top* of your underlying transport.  So the spread datagram goes
to your virtual network device, gets bundled into an IP frame (with the
virtual address), encrypted, and then *that* gets sent over the real TCP/IP
link.  That's more overhead than I'd really like to deal with if I can avoid

I already tunnel various things over SSH, which I'm using for console access
anyway.  Now I *could* add a second secure system, like IPSEC or something
based on SSL, but that's yet another crypto product to maintain, watch for
vulnerabilities, etc.  Just keeping up with SSH is getting to be enough

On Wed, 9 Jan 2002 11:59:29 -0500
Theo Schlossnagle <jesus at omniti.com> wrote:

> On Wednesday, January 9, 2002, at 11:45  AM, Mark Anacker wrote:
> > I'll probably have to do something like this in the near-term, but 
> > it's a
> > bit of a pain. Mostly due to the overhead of encapsulating a 
> > nearly-complete
> > IP stack on top of the existing TCP stream.  But, since I don't want
> > un-encrypted UDP flowing out (or in) through the firewall, I have to 
> > carry
> > it over TCP.  Call me paranoid, but it's a bit easier to keep tabs on a
> > small set of TCP links than trying to filter whatever UDP packets come
> > along.
> >
> > It would still be cleaner if the daemon itself could create a virtual
> > segment over TCP to another daemon.
> It isn't unencrypted in my scenario...  I have an IPSEC VPN between the 
> two locations and I route between Spread segments over that.  The VPN 
> could care less that it is UDP or TCP.  My UDP flows well and is 
> encrypted and authenticated (between VPN points).
> --
> Theo Schlossnagle
> 1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
> 2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7

Mark Anacker
Senior Software Architect
Copyright 2002, LizardTech, Inc. All rights reserved.  Unauthorized
disclosure prohibited.

More information about the Spread-users mailing list