Summary

  • RFC 3078’s coherency count could reveal a missing or out-of-order MPPE packet. It could not reconstruct the lost ciphertext, prove the following packet was decryptable or restore the application data that never arrived.
  • Stateless mode could advance its key state across a count gap. Stateful mode instead required the receiver to drop traffic, send a CCP Reset-Request and wait for the sender’s FLUSHED packet before treating the cipher tables as synchronized again.

The revealing packet was also unusable

Consider the first MPPE packet received after an earlier packet disappeared. Its header carries a coherency count that does not match the receiver’s expectation. The count is useful precisely because it makes the absence visible. Yet, in RFC 3078’s stateful mode, the new packet may have been encrypted after a key-change boundary that the receiver never saw. The receiver knows the sequence is broken but may no longer possess the cipher state needed to read what has just arrived.

The protocol’s answer was not to guess. The receiver had to drop the packet, send a Compression Control Protocol Reset-Request without data, and silently discard later packets until the sender supplied one with the FLUSHED bit set. The sender, after receiving the request, reinitialized its RC4 tables and marked the next packet so the receiver could do the same. No Reset-Ack was required; the marked data packet was the operative boundary.

This small state machine contains a larger historical lesson. A field can diagnose a broken transition without reversing it. A reset can restore the ability to continue without recovering what was lost. A new synchronized state can be real while the interrupted application has already suffered an irreversible gap.

Encryption began only after several other decisions

RFC 3078 was published in March 2001 as an Informational RFC. It described Microsoft Point-to-Point Encryption for PPP-encapsulated traffic and updated the option space shared with Microsoft Point-to-Point Compression in RFC 2118. It did not become an Internet Standard.

MPPE was negotiated through option 18 of PPP’s Compression Control Protocol. The initiator was expected to offer the options it supported. The responder could reject that set with a single preferred encryption choice, ordinarily the strongest mutually offered choice: 128, 56 or 40 bits. A separate bit asked for stateless operation. If MPPE negotiation was never attempted, the default was no encryption. If it was attempted and failed, RFC 3078 said the link should be terminated.

Those distinctions matter operationally. Authentication success was not encryption. Possession of a session key was not an opened CCP state. An offered 128-bit option was not a selected 128-bit mode. A policy requiring encryption was not evidence that user packets had waited for negotiation to finish. RFC 3078 required PPP to reach Network-Layer Protocol phase and CCP to reach Opened before any MPPE packet was transmitted.

The documents around it deliberately divided the chain. RFC 2548 described how RADIUS could carry separate MPPE send and receive keys. RFC 3079 described derivation of MPPE keys from authentication material. RFC 1962 supplied CCP negotiation and reset machinery. RFC 1661 supplied PPP’s link phases. RFC 3078 owned the live encrypted-packet state. No single record from one layer proved the others.

Twelve bits remembered position, not payload

Every MPPE packet carried a twelve-bit coherency count. The sender incremented it for each packet and wrapped it from 4095 to zero. A receiver compared the observed value with the state it had retained. The field provided a compact way to detect ordering and loss conditions and to decide how far key state might need to move.

The counter did not contain the missing packet. It did not authenticate why the count changed. It did not reveal whether a packet vanished on the link, was discarded by a queue, was filtered, arrived out of order or was modified by an attacker. It did not prove that packets with consecutive counts had reached an application. It was a protocol-state observation, not an end-to-end delivery receipt.

RFC 3078 said MPPE did not require a reliable link and usually did not benefit from adding the reliable-transmission mechanism of RFC 1663 merely for synchronization. That sentence can be misread. “Does not require a reliable link” did not mean that packet loss became harmless or that missing data reappeared. It meant the encryption state machine had defined reactions to loss. Applications and upper-layer protocols still owned the consequences of absent data.

Only a particular range of PPP protocols passed through MPPE. Other PPP packets retained their original protocol numbers. The encrypted-data bit identified whether an MPPE payload was encrypted, but the bit was not a cryptographic proof. The packet header itself remained part of a control surface on which receiver state depended.

Stateless mode paid computation to avoid a return reset

In stateless mode, the session key changed whenever the coherency count changed—normally once per packet. The sender advanced the key before encryption. The receiver advanced it after observing the new count but before decryption. The FLUSHED bit was set on every encrypted packet.

If the receiver last saw count two and next received count five, it performed three key changes before attempting to decrypt the new packet. The count gap told it how far the sender’s key evolution had moved. Because every stateless packet carried the reinitialization indication, the receiver did not need a CCP Reset-Request merely to resynchronize.

That mechanism made continuation possible after skipped ciphertext. It did not restore counts three and four. Nor did it prove that repeated key advancement was caused by ordinary loss rather than manipulated headers. The receiver could regain the right key for the packet in hand and still have no evidence of the missing application content.

Statelessness was therefore not absence of state. Both peers still needed the starting key, the count history, the deterministic key-change function and agreement on mode. “Stateless” localized recovery into each received packet; it did not abolish the shared contract.

Stateful mode made the reverse path part of decryption

Stateful mode changed keys less frequently. The sender changed before packets whose low-order count octet equalled 0xFF; the receiver changed after receiving, but before decrypting, the same flag packet. If that particular packet was lost, the sender advanced while the receiver did not.

A later count could expose the discontinuity. The receiver might perform the expected key change, but RFC 3078 still required a reset exchange after stateful loss. It dropped the revealing packet, sent Reset-Request, and discarded traffic until FLUSHED arrived. The sender’s response was not an acknowledgement object. It was changed behavior: reinitialize and mark the next packet.

The return control path thus became part of the forward data path’s recovery. A monitor that saw only sender-to-receiver encrypted packets could detect a gap and perhaps a later FLUSHED mark, but it could not prove that the receiver sent the request or that the sender acted on that specific request. A monitor that saw only the Reset-Request could not prove a usable marked packet returned. Both directions, their timing and the first successfully decrypted post-reset payload belonged in the receipt.

RFC 3078 also warned that stateful reinitialization could cause two packets to use the same key. It therefore advised against stateful mode on lossy environments such as layer-two tunnels over the Internet. That warning did not say every stateful session had failed or that stateless mode made RC4 modern. It identified a specific interaction between loss, reset behavior and key reuse.

Negotiation could be changed before the first protected byte

The security section placed another boundary upstream. MPPE negotiation was not integrity protected. An active attacker could modify the Supported Bits field and alter the apparent strength. Configuration could limit the effect—for example, by refusing unacceptable modes—but the protocol exchange itself did not authenticate its choice.

An attacker could also change a coherency count and cause the peers to lose synchronization, or invert the encrypted-data bit to mount a denial-of-service attack. These warnings make it unsafe to elevate a header observation into a trusted audit claim. The evidence chain needs both what appeared on the wire and what each configured peer accepted.

Historical accuracy also requires resisting retrospective endorsement. RFC 3078 used RC4 and described 40-, 56- and 128-bit variants. RFC 4345 later proposed improved RC4 modes for SSH, a different protocol and construction. That later work is useful as a reminder that “128-bit” is not a complete security assessment. It is not evidence that MPPE migrated, remained deployed or acquired the properties of later mechanisms.

The proper receipt is a chain of transitions

For a stateful MPPE session, preserve the authentication result and the origin of initial key material without exposing the secret. Preserve the direction-specific key identity, PPP session and peer identities, every CCP request, rejection and acknowledgement, the selected key length and mode, and the moment CCP reached Opened.

For each encrypted direction, retain the configuration epoch, expected and observed coherency counts, wrap events, FLUSHED and encrypted-data bits, count gaps, flag-packet boundaries, dropped ciphertext, Reset-Request transmissions and receptions, packets discarded while waiting, table reinitialization and the first successfully decrypted packet after recovery. Continue past the cipher: record the upper-layer protocol, application sequence or acknowledgement and the outcome that the service actually promised.

This is Lu Heng’s reality-layer discipline applied to a compact encryption protocol. Credential acceptance, key derivation, key delivery, option negotiation, packet receipt, loss observation, synchronized cipher state, plaintext recovery and application delivery are not synonyms. Running code connects them only when the transitions occur and leave evidence.

The coherency count did honest work. It named a discontinuity. Its historical importance lies in refusing to ask that small field to do more than it could.

Sources