> OK, now that we have come down to publishing the who's who in the network
> community... I'd like to take advantage of this great opportunity to pose a
> question. Since M$ came out with PPTP and had it incorporated into their
> server products, why did they migrate to IPSEC on Win2k? Is the fact that
> the packets cannot be rewritten the reason? Is that a potential problem
> with other encryption techniques that IPSEC stands out from? How then does
> CIPE and the other technologies compare?
PPTP has been heavily criticized as not very secure. That's probably
one reason M$ is moving away from it.
Another likely reason is more complex. When people say "PPTP", they
usually mean PPTP (which is unencrypted) with MPPE encryption and
sometimes MPPC compression. MPPC is patented, and M$ doesn't own the
patent ... or at least not the valid one. Supposedly the patent
office issued two patents for the same algorithm, and M$ was second in
line, lost a court battle, and had to pay up.
PPTP also has a weird setup. It uses PPP to negotiate the encryption,
but nominally PPP has no provision for negotiating encryption. PPP
does have the ability to negotiate compression, so MPPE encryption is
stuck in as a "compression" that doesn't compress, with MPPC then
added as another compression, one that actually does compress.
Initially, MPPE used only 40-bit keys. You could upgrade later to
128-bit keys, but only under the usual US-only restrictions. (MPPE
has provision for 56-bit keys, but I've never seen one used.)
I don't know how good the 128-bit encryption is, but it doesn't
matter. Having begun with a 40-bit key and with the US-only nonsense
about longer keys, MPPE is stuck with a bad reputation it's not going
to live down no matter how good its longer-key encryption may be.
The PPTP/MPPE/MPPC implementation of Windows 95/98 also had really
poor performance. It was designed for dialup, and it could make DSL
or a cable modem seem like dialup. The Windows 2K PPTP works much
better, but again PPTP isn't going to live down its reputation as a
dog any time soon.
There was plenty of reason to move on. With IPsec out there as an
IETF-sponsored standard, it was the obvious choice for any vendor.
The CIPE FAQ comments:
As for CIPE vs. IPSEC, they should be equivalent security-wise,
with CIPE giving a bit better performance because of the
lightweight protocol. However, IPSEC is standardized and thus has
better interoperability.
Interoperability here mean interoperability in the sense Jason means
it: if you have to connect to equipment that only runs IPsec, then you
too have to run IPsec. However, in the sense that I think is more
important, all VPN technologies are interoperable, because it doesn't
matter how you connect networks.
An IPsec-based VPN and a CIPE-based VPN can be joined by putting a
CIPE-speaking box on a DMZ segment of the IPsec-based VPN or by
putting an IPsec-speaking box on a DMZ segment of the CIPE-based VPN.
(For that matter, you could join them by putting an OpenVPN-speaking
box on a DMZ segment of each.)
What it comes down to is that if you limit your VPN to IPsec-speaking
boxes, then you limit your VPN to IPsec-speaking boxes. If you don't,
you don't.
CIPE was originally developed for Linux, but it's been ported to
Win2K, so boxes that could talk CIPE are common on most networks.
--
Dick St.Peters, [EMAIL PROTECTED]
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
