Re: CIPE for msw-to-msw vpn|
"Damion K. Wilson" <dkw,AT,rcm,DOT,bm>|
Tue, 31 Oct 2000 17:25:51 +0100|
Before I committed to CIPE for the company's VPN, I went through all the
major commercial and open source implementations. Here's a brief summary of
my findings :-
a) IPSEC is not finished. It also has problems working through firewalls
esp. masquerading ones. Not all implementations coexist, either.
b) PPTP. Need I say any more
c) L2TP + IPSEC. Ok if all you are going to use for your network
infrastructure is Windows 2000 and (expensive) Cisco gear.
d) All the others, both hardware and software implementations, have no
interoperability (i.e. standards-less).
Furthermore, many VPN vendors appear top believe that the firewall will
also be the VPN external "hub". This, I believe, is a patently silly
assumption. I firmly assert that any VPN endpoint should be on a separate
host and behind the firewall.
The CIPE keys are just randomly selected 128 bit numbers. Each host
independently decides what key it will use to encrypt further messages to
the peer and then sends that key to the peer (encrypted with the old key)
so that that peer can continue to decrypt packets.
*********** REPLY SEPARATOR ***********
On 10/31/00 at 10:08 AM Brendan J Simon wrote:
>"Damion K. Wilson" wrote:
>> Yes. That's what I wrote it for, specifically. There are some firewall
>> convolutions you'll probably have to do if your firewall is using NAT.
>> I don't agree that it's a good idea to run the VPN software on the
>> firewall. I always place it behind the firewall and establish firewall
>> rules to allow the traffic. You CAN. of course. set it up anyway you
>I agree with you too and this is what I intend to implement, once I decide
>the best VPN solution. Do you know if IPSEC is ready to use with Win2000
>It seems this is the preferred VPN solution according to various VPN sites
>I think even Bruce Schneier advocates it, though I have heard of some
>government agecies mocking it.
>> CIPE uses a shared, static key between peers initially and then
>> randomly selected session keys during operation. If the static key is
>> compromised, then you are potentially hosed. However, this key is never
>> transmitted, the session keys are themselves transmitted as packets
>> encrypted with the preexisting session key or static key.
>How are the shared/static keys generated and updated. Are the keys
>> There are some commercial solutions that require you to "do it their
>> but still have merit. The only other open source implementation of merit
>> that I can think of is TUN/TAP. They are currently porting to Win32 but
>> now on Solaris and Linux.
>I don't know about this one. I've been to the Tunnel Vision page but
>runs over TCP, which sounds like a bad idea according to the CIPE page.
>Thanks very much for your thoughts and advice,