need explanations

[Bennett Todd]

2000-07-11-17:08:06 Darrin Mourer:
> I'm researching the different types of encryption available for
> VPN's and there doesn't seem to be any good single point of
> reference for this exact type of information on bandwidth cost,
> comparisons, and cryptoanalysis tests/results. Any suggestions?

It's always bad form to followup your own posts, but as usual in
such cases, when I read my followup I realized that I hadn't
addressed much of the question as posed.

In terms of bandwidth cost, it shouldn't be much for any VPN; a
reasonable VPN design might compress the data before encrypting it,
partly for the performance win and partly to make cryptanalysis
harder still. If so, then there should be a bandwidth win to the
VPN, unless it's carried over links that would otherwise compress
the traffic, in which case the bandwidth consumption difference
should be negligible. If on the other hand the VPN does not compress
the payload, and something else on the links would have compressed
the traffic if it could have, then the incompressibility of
encrypted traffic would be a bandwidth hit, whose severity would be
the compression efficiency that has been lost. Real-time stream
compression algorithms, suitable for link-level compression, rarely
exceed 2:1 unless the underlying traffic happens to be unusually
compressible --- big blocks of NULs or whatever. So there can be a
hit in this one case, usually not too awful.

Rather than bandwidth the question might be performance. For speeds
in excess of DS3 (c. 45Mbps), an exceptionally good implementation
of crypto on an exceptionally hot processor might be needed, or a
hardware implementation might be in order. These are available. In
the neighborhood of 10Mbps--DS3, I'd expect a decent implementation
on a modern CPU to keep up no problems. Below 10Mbps there shouldn't
be a performance issue with the crypto.

Then there's the overall performance of the VPN solution. The
single most critical factor I know of in that topic
is nicely, even elegantly addressed in the article
"Why TCP Over TCP Is A Bad Idea", available from
<URL:http://sites.inka.de/sites/bigred/devel/tcp-tcp.html>. Don't
look to PPP-over-ssh, vpnd, or any other solution that tunnels IP
over a TCP link to do VPN, if performance is a concern --- unless
the underlying link has nearly perfectly consistent and uniform
performance with neglible losses or variations in latency. I.e. it
may be reasonable on a purely dedicated link, if you can actually
find a competant provider to buy your bandwidth from, but don't try
it over the internet:-).

As for cryptanalysis, that would divide into two parts; the
algorithms and protocols used should be worthy (that's the only
thing I addressed in my previous tract), and the implementation
needs to be good. When I want a good implementation, I go to open
source, since there's at least a chance that the code in question
might actually get the auditing it seriously needs. Other people
look for their reassurance in other ways.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/vpn/attachments/20000713/354a35cb/attachment.pgp