From 67ccbff7ff8402cce48d15994713c196f683a280 Mon Sep 17 00:00:00 2001 From: "David F. Skoll" Date: Tue, 2 Apr 2002 13:55:48 +0000 Subject: [PATCH 1/1] Add README.MPPE --- README.MPPE | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 README.MPPE diff --git a/README.MPPE b/README.MPPE new file mode 100644 index 0000000..afac600 --- /dev/null +++ b/README.MPPE @@ -0,0 +1,81 @@ +PPP Support for MPPE (Microsoft Point to Point Encryption) +========================================================== + +Frank Cusack frank@google.com +Mar 19, 2002 + + +DISCUSSION + +MPPE is Microsoft's encryption scheme for PPP links. It is pretty much +solely intended for use with PPP over Internet links -- if you have a true +point to point link you have little need for encryption. It is generally +used with PPTP. + +MPPE is negotiated within CCP (Compression Control Protocol) as option +18. In order for MPPE to work, both peers must agree to do it. This +complicates things enough that I chose to implement it as strictly a binary +option, off by default. If you turn it on, all other compression options +are disabled and MPPE *must* be negotiated successfully in both directions +(CCP is unidirectional) or the link will be disconnected. I think this is +reasonable since, if you want encryption, you want encryption. That is, +I am not convinced that optional encryption is useful. + +While PPP regards MPPE as a "compressor", it actually expands every frame +by 4 bytes, the MPPE overhead (encapsulation). + +Because of the data expansion, you'll see that ppp interfaces get their +mtu reduced by 4 bytes whenever MPPE is negotiated. This is because +when MPPE is active, it is *required* that *every* packet be encrypted. +PPPD sets the mtu = MIN(peer mru, configured mtu). To ensure that +MPPE frames are not larger than the peer's mru, we reduce the mtu by 4 +bytes so that the network layer never sends ppp a packet that's too large. + +There is an option to compress the data before encrypting (MPPC), however +the algorithm is patented and requires execution of a license with Hifn. +MPPC as an RFC is a complete farce. I have no further details on MPPC. + +Some recommendations: + +- Use stateless mode. Stateful mode is disabled by default. Unfortunately, + stateless mode is very expensive as the peers must rekey for every packet. +- Use 128-bit encryption. +- Use MS-CHAPv2 only. + +Reference documents: + + MPPE + MPPE Key Derivation + MPPC + PPTP + MS RADIUS Attributes + +You might be interested in PoPToP, a Linux PPTP server. You can find it at +. + +RADIUS support for MPPE is from Ralf Hofmann, . + + +BUILDING THE PPPD + +The userland component of PPPD has no additional requirements above those +for MS-CHAP and MS-CHAPv2. The kernel, however, requires SHA-1 and ARCFOUR. +Public domain implementations of these are provided. Until such time as +MPPE support ships with kernels, you can use the Linux-2.2 implementation +that comes with PPPD. Run the linux/mppe/mppeinstall.sh script, then +rebuild your kernel. The ppp_mppe.o module is added, and the ppp.o module +is modified (unfortunately). You'll need the new ppp.o since it does the +right thing for the 4 extra bytes problem discussed above. + + +CONFIGURATION + +See pppd(8) for the MPPE options. Under Linux, if your modutils is earlier +than 2.4.15, you will need to add + + alias ppp-compress-18 ppp_mppe + +to /etc/modules.conf. (A patch for earlier versions of modutils is included +with the kernel patches.) + + -- 2.39.2