[Spread-users] Tunnels

[Theo Schlossnagle]

On Wednesday, January 9, 2002, at 12:20  PM, Mark Anacker wrote:
> 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
> it.

I understand how that works.  It gets sent of an IP link... IPSEC 
provides a secure IP layer.  TCP/IP.. UDP/IP.. call it whatever suits 
you.  That is exactly what happens in my set up.  I can do 100Mbs solid 
between my VPNs (encrypted).  They are dedicated hardware devices.  
Their real IP addresses are firewalled so that they can only see each 
other only are only visible to each other.

The latency involved when encrypting the packets and encapsulating in a 
new IP frame is negligible compared the latency between my sites.

> 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
> work...

Tunneling things over ssh is SLOW unless you have a hardware card 
supported by openssl and utilize that.  Besides, you machine is busy 
doing other things and shouldn't be bogged down with encryption. Spread 
is pretty CPU hungry when you start pushing heavy traffic.

As for administrating yet another configuration...  Your network admin 
should be responsible for that.  If you are the network admin -- its 
your job ;-)  Basically, my opinion is that you need a solution or you 
don't.  The IPSEC solution that I use is probably the most cost 
effective solution for my needs.  UDP and TCP have little bearing on the 
solution if implemented correctly.

--
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