About MPPE and MPPC

MPPE stands for Microsoft Point-to-Point Encryption. It is a protocol designed for transfering encrypted datagrams over point-to-point links. See RFC3078 and RFC3079 for details.

MPPC stands for Microsoft Point-to-Point Compression. It is a protocol designed for transfering compressed datagrams over point-to-point links. The MPPC algorithm uses an LZ based algorithm with a sliding window history buffer. See RFC2118 for details.

Although the module's source code is completely free, MPPC itself is patented algorithm. Patent for *Microsoft* PPC is holded by the Hifn Inc. This is obvious ;-). Furthermore, MPPE uses RC4[1] encryption algorithm which itself isn't patented, but RC4 is trademark of RSA Data Security Inc. To avoid legal problems, US citizens shouldn't use this module.

OK, you have been warned, now you can do whatever you want.

MPPE/MPPC violate Compression Control Protocol: when decompression error occurs, receiver sends CCP ResetReq, sender resets the compressor but doesn't send CCP ResetAck which it should do if it would be fully CCP compliant. In my opinion it's very funny - probably guys from Hifn Inc. didn't want to pay royalties to Motorola which holds patent on this "technology". ;-) I love software patents. ;-)

Why have I written this module?

Besides Stac LZS, MPPC seems to be the most common compression algorithm used in (remote/network) access servers. On the one hand Internet Service Providers often set up their AS to support only the two mentioned algorithms and on the other hand AS often support only those algorithms - in my opinion this is result of implementation MPPC/MPPE and LZS in silicon. See http://www.hifn.com if you want to know more or if you want to buy such a chip. So they are de facto standards; Hifn's marketroids call them even industry standards. :-) At the client side, MPPE/MPPC is of course supported by Microsoft operating systems.

Some day, digging in the Net, I found MPPE implementation at http://mirror.binarix.com/ppp-mppe/.[2] I thought that it would be good to complete that code with MPPC and make it freely available. So I wrote MPPC part and added support for 56 bit keys in MPPE.

Download

Installation

• Download kernel patch: linux-2.6.13-mppe-mppc-1.3.patch.gz or linux-2.4.31-mppe-mppc-1.3.patch.gz,

• Download pppd-2.4.3,

• Download pppd patch: ppp-2.4.3-mppe-mppc-1.1.patch.gz

• Apply patches to the kernel and pppd,

• Do eg. "make menuconfig". In "Network device support" choose "PPP (point-to-point protocol) support" and then mark "Microsoft PPP compression/encryption (MPPC/MPPE)",

• Mark SHA1 and RC4 algorithms in CryptoAPI's configuration menu,

• Compile kernel and pppd,

• If you have compiled MPPE/MPPC as module, add to your /etc/modules.conf following line:

  alias ppp-compress-18 ppp_mppe_mppc

Usage

By default pppd tries to negotiate MPPC and don't negotiate MPPE but will agree if peer wants encryption. If peer supports a few key lengths, according to RFC3078 pppd will choose the strongest one.

mppe suboptions:

• required - make MPPE obligatory, disconnect if peer doesn't support MPPE

• stateless - try to negotiate stateless mode

• no40 - disable 40 bit keys

• no56 - disable 56 bit keys

• no128 - disable 128 bit keys

Examples:

• pppd [options] - try to negotiate MPPC, MPPE is optional

• pppd nomppe [options] - try to negotiate MPPC and disable MPPE; peer will disconnect if it requires MPPE

• pppd nomppc [options] - disable MPPC; MPPE is optional

• pppd mppe required,stateless,no128 [options] - try to negotiate MPPC, require MPPE in stateless mode and disable 128 bit keys; pppd will disconnect if peer doesn't support MPPE

Performance

I have no idea how to measure, in a simple way, (de)compressor performance when it runs in kernel space. So I have written a small program which uses the same (de)compression algorithm and runs in user space. It allows to estimate (de)compression speed and compression ratio. I have tested my code on Calgary Text Compression Corpus. The last row in the table below is result of tests on U.S. Constitution. I have run test on three machines:

• System 1: Pentium III 600MHz, Linux 2.4.18

• System 2: 2 x Pentium II 350MHz, Linux 2.4.16 SMP

• System 3: UltraSparc II 164MHz, Solaris 7

The table below presents performance of Hifn's MPPC implementation written in C. They have done tests on plain text file containing the U.S. Constitution. I haven't such old PC's so I couldn't repeat their tests. But my UltraSparc and their Pentium have comparable performance in fixed point therefore you can more or less estimate my implementation's quality. ;-) One can see that compressor is quite good, however decompressor needs some work.

Changes

2005-02-02; version 1.3:

• ppp_mppe_mppc.c: resolved the problem with "Kernel doesn't provide ARC4 and/or SHA1 algorithms..." when the module is statically linked into a 2.4.x kernel; thanks to Marlon de Boer who has pointed out the problem and solution

2004-11-23; version 1.2:

• ppp_mppe_mppc.c: fixed bug related to CryptoAPI's SHA1; thanks to Oleg Makarenko who is the first person who has suggested the solution

2004-08-15; version 1.1:

• ppp_mppe_mppc.c: the module uses CryptoAPI's SHA1 implementation once again,

• Kconfig, Config.in: choosing MPPE/MPPC automatically switches on SHA1 and RC4,

• sha1.c, sha1.h: unsigned long variables changed to u_int32_t so pppd should now work without any problems on 64 bit architectures

2004-04-09; version 1.0:

• ppp_mppe_mppc.c: fixed a subtle bug in stateful mode synchronization code - the compressor didn't change its RC4 key before sending a frame with FLUSHED bit set; the peer silently dropped wrongly encrypted frames and the connection looked like locked up; the bug could be observed only when MPPC and MPPE were used at the same time and a compressed file (e.g. a JPEG or MP3) was transfered,

• ppp_mppe_mppc.c: built in SHA1 functions reverted; CryptoAPI's SHA1 sometimes causes kernel crash and I am not able to find the bug,

• ppp_generic.c: fixed size of the compressor's output buffer,

• ppp-comp.h: unnecessary macros removed

2004-04-04; version 1.0-test1:

• ppp_mppe_mppc.c: added missing try_module_get() in mppe_alloc() and module_put() in mppe_comp_free() in the patch for 2.6.x kernels,

• ppp_mppe_mppc.c: calls to built in RC4 and SHA1 implementations removed - now the module uses CryptoAPI,

• ppp_mppe_crypto.{c,h}: files removed - now the module uses CryptoAPI,

• ppp_mppe_mppc_comp.c: file name changed to ppp_mppe_mppc.c,

• ccp.c (pppd patch): fixed wrong stateful/stateless mode negotiation when MPPE was configured as optional and peer requested stateless mode,

• ccp.c (pppd patch): fixed MTU bug (at least I hope so because personally I have never noticed such problem) - it caused that some websites were not loaded (especially SSL sites or sites behind a loadbalancer); I have used idea suggested by Pasi Kärkkäinen on linux-ppp mailing list

2004-03-05; version 0.99:

• ppp_mppe_mppc_comp.c: fixed "Unsupported protocol 0x2145 received" problem - frames with compressed protocol field were not recognized properly; the problem occured sometimes when one tried to connect to a Watchguard Firebox or a {Free, Open, Net}BSD box running mpd; this is not a MPPC/MPPE implementation bug but rather inaccurate specification - in contradistinction to RFC1977 and RFC1979, RFC2118 and RFC3078 does not specify clearly if PFC should be applied or not prior to compression/encryption; this causes incompatibility with older versions

2003-08-07; version 0.98:

• ppp_mppe_mppc_comp.c: fixed MPPE key reinitialization after receiving CCP_RESETREQ in mppe_comp_reset() (thanks to Shoichi Saito for pointing that)

2003-07-17; version 0.97:

• ppp_mppe_mppc_comp.c: fixed coherency counter handling in stateless mode (thanks to Anders Brownworth for pointing that),

• ppp_mppe.c: file name changed to ppp_mppe_mppc_comp.c; binary module name changed to ppp_mppe_mppc.o,

• ppp_generic.c: fixed buffer overflow which occured in some situations

2002-11-23; version 0.96:

• ppp_mppe.c: fixed kernel oops introduced in version 0.95

2002-11-20; version 0.95:

• ppp_mppe.c: fixed synchronization code in mppe_decompress(),

• ppp_mppe.c: removed mppe_initialize_key() and changed mppe_change_key(),

• SHA1 and RC4 functions moved to ppp_mppe_crypto.c,

• ppp_mppe.c: added function mppe_decomp_reset()

2002-08-30; version 0.94:

• ppp_mppe.c: slightly improved compressor performance,

• ppp_mppe.c: if MPPC and MPPE is negotiated, flush history buffer when MPPE key changes

2002-08-20; version 0.93:

• ppp_mppe.c: removed bug in mppc_decompress() which occured when overlapped memory areas was copied (many thanks Wilfried),

• ppp_mppe.c: added protections against buffer overflows,

• ppp_mppe.c: reset flag (bit B) was set unnecessarily when coherency counter reached zero in mppc_compress() (thanks again Wilfried)

2002-06-28; version 0.92:

• ppp_generic.c: don't set SC_DC_ERROR flag after decompression error when MPPE/MPPC is negotiated; in other words - don't wait for CCP_RESETACK after CCP_RESETREQ

Known bugs

• Current kernel patches use CryptoAPI's SHA1. Unfortunately, for some reason in rare cases the patches doesn't want to work properly: you may notice "Unsupported protocol..." messages or even kernel crash. If such a situation occurs, please download this file for 2.6.x. kernels (or this for 2.4.x), copy it to KERNEL_ROOT_DIR/drivers/net/ppp_mppe_mppc.c and then recompile the kernel and modules.

  The only difference is that these files use built-in SHA1 instead of CryptoAPI's SHA1.

  This bug has been fixed in version 1.2.

Acknowledgements

Acknowledgements go to:

• Anders Brownworth for testing and a good will,

• Sergio M. Ammirata for testing and donating iPAQ 3875,

• Wilfried Weissmann who spent a lot of time on debugging,

• Shoichi Saito,

• Jeo Liu,

• others who have sent me bug reports.

Feedback

If you have found a bug or have any comments, improvements, etc. do not hesitate to send them to <jdx(at)slackware.pl>.

If you have questions regarding set up, please make sure that your problem is not trivial. A lot of people use the module successfully, so probably you are making a mistake. I am sorry, I am tired to write the same answers over and over again. Trivial problems will be simply ignored.

Because English is not my native language, any corrections are welcome.