Summary

  • RFC 1969 made the last ciphertext block of one PPP packet the CBC input for the next, reducing repeated setup but coupling each packet’s decryptability to its predecessor.
  • A clear 64-bit nonce seeded the first chain through the secret DES key; a 16-bit sequence number exposed ordering gaps, but neither field authenticated the peer or protected the ciphertext from modification.
  • Losing packet N-1 makes both N-1 and N plaintext unavailable. If N ciphertext arrived, however, its final block lets the receiver decrypt N+1; synchronization returns, lost data does not.

The two-packet shadow

Imagine three encrypted packets in flight: N-1, N, and N+1. The first disappears. The second reaches the receiver intact, but its plaintext cannot be recovered because CBC needs the final ciphertext block of N-1. The third arrives next. Curiously, it can be decrypted, because the receiver did receive the ciphertext of N and can take its final block as the required chaining value.

That is the compact recovery argument in RFC 1969. The loss casts a shadow one packet longer than the missing datagram: N-1 is absent and N is computationally stranded. The shadow ends at N+1, provided the receiver retained N even though it could not turn that ciphertext into useful plaintext.

Calling this “recovery after packet loss” is accurate only at the state boundary. The decryption chain recovers. The lost information does not. No retransmission is specified here, no application record is reconstructed, and no PPP upper layer is told that its missing work somehow reappeared. The mechanism restores the ability to process later packets.

Why carry the chain across packets?

RFC 1969, published as Informational in June 1996, specified one bearer protocol for the generic PPP Encryption Control Protocol. Its authors chose the US Data Encryption Standard in Cipher Block Chaining mode. Inside a packet, each plaintext block is XORed with the previous ciphertext block before DES encryption. RFC 1969 then made a consequential additional choice: after the first packet, the next packet begins with the last ciphertext block of the previous packet rather than with a fresh per-packet initialization value.

The choice keeps the encrypted stream continuous. Identical plaintext sequences need not produce identical ciphertext merely because they occupy the same place inside separate packets. It also avoids carrying a new initialization vector with every encrypted datagram. But it turns packet order into a cryptographic input. PPP may present packet boundaries; CBC state does not respect them.

This is the design’s efficiency–recovery coupling. Reusing the stream’s terminal state saves per-packet material and extends chaining, while making one packet depend on evidence outside itself. A capture containing N alone does not contain all inputs required to decrypt N. The missing input is not secret metadata hidden elsewhere; it is the previous packet’s final ciphertext block.

The article therefore begins after the negotiation framework described by RFC 1968. ECP has already reached Opened, an encryption option has already been accepted for a direction, and encrypted datagrams use the assigned PPP protocol. The question here is narrower: what evidence does a DESE packet and its surrounding sequence actually provide?

A public nonce and a private key do different jobs

The DESE configuration option is ten octets long: a Type, a Length, and an eight-octet Initial Nonce. The receiving implementation offers the nonce that its peer will use to encrypt the first packet sent toward it. RFC 1969 says the nonce is exchanged in the clear and recommends a different value for each ECP negotiation to guard against replay. Its example combines seconds since 1 January 1970 with nanoseconds inside the current second.

The first CBC input is not the clear nonce by itself. The sender computes E[k](Initial Nonce) under the 56-bit shared DES key and uses that result as C[0]. The receiver, which sent the nonce and possesses the same key, performs the matching computation. From the second packet onward, C[0] is simply the last ciphertext block of the previous packet in sequence space.

This division is easy to blur. The nonce contributes freshness to the starting state. It is deliberately observable and cannot function as the secret. The DES key supplies secrecy, but RFC 1969 does not say how the parties obtain it. It says manual configuration is usual and suggests that PPP authentication or a Multilink Endpoint Identifier might be factors in selecting a shared secret. Authentication and secret retrieval remain exterior and unspecified.

A packet trace can therefore record the offered nonce and the negotiated DESE option without proving that the right peer held the intended key. A successful decryption is stronger operational evidence, but even it is not an authenticated statement from a named organization or user. It shows that some endpoint possessed compatible state and key material.

The sequence number is an alarm, not a seal

Every DESE data packet carries a 16-bit sequence number, starting at zero after ECP reaches Opened and advancing with encrypted packets. The receiver compares consecutive values to detect a discontinuity. That exposed numbering is what makes the loss window intelligible: after seeing a gap, the receiver knows not to treat the next packet as though it followed the last successfully processed ciphertext.

The sequence number does not participate in a cryptographic integrity calculation in this specification. It is visible, finite, and unauthenticated by any mechanism RFC 1969 defines. It does not tell the receiver whether ciphertext bits were altered, whether a packet was replayed by an attacker, whether the sender is the intended party, or why a number is absent. Loss, corruption, reordering and active interference can all disturb the observed sequence.

Nor does decryptability itself close those gaps. CBC confidentiality is malleable without a separate integrity mechanism. RFC 1969’s short security section says that the proposal relies on external authentication and shared-secret handling and inherits every limitation of DES. Its replacement, RFC 2419, states the boundary more explicitly: the mechanism provides confidentiality only, not integrity, authentication or nonrepudiation, and does not guarantee resistance to replay, cut-and-paste or active tampering.

This does not make the sequence number useless. It makes it precise. It is evidence about expected order in one DESE direction. Treating it as a seal of authenticity destroys that precision.

Padding makes packet size a negotiated operational fact

DES consumes blocks of eight octets. A PPP Protocol field plus Information field rarely lands conveniently on that boundary, so DESE may enlarge a packet before it adds its two-octet sequence number and outer protocol framing.

RFC 1969 distinguished between protocols with an explicit length field and those vulnerable to trailing garbage. For IP, IPX, XNS and CLNP, it permitted random trailing padding because the receiver could use the inner length. For bridging and other cases where garbage would change interpretation, it referred to the self-describing padding defined in RFC 1570. That padding can cost a full eight octets when an already aligned plaintext ends with bytes that look like a pad suffix.

The MRU example is deliberately uncomfortable. If Protocol Field Compression is active and the original MRU is exactly a multiple of eight, a full-size packet plus a one-octet Protocol field may need seven pad octets. Add the two-octet sequence number and the outer protocol effect, and the DESE Information field can be ten bytes larger than the original. Negotiating DESE does not automatically raise the MRU because PPP options are independent.

This is more than capacity trivia. A receiver must know which bytes are content and which are padding before it can hand the reconstructed packet upward. Under RFC 1969, that judgment depended partly on the encapsulated protocol. Two implementations could disagree about which protocols were safe to trail with garbage.

Why RFC 2419 replaced the original

The RFC Editor record says RFC 2419 obsoletes RFC 1969. The later document’s own differences section gives the reason without requiring speculation. DESE-bis applies a single self-describing padding rule to all plaintext packets, independent of whether PPP’s separate Self-Describing-Padding option was negotiated. It fixes the maximum at eight octets and tells a receiver to discard a frame whose pad bytes do not match the pattern.

Because the new rule could cause a packet to be interpreted differently by an implementation following RFC 1969, DESE-bis received a new ECP type: 3. The former type 1 was deprecated; a conforming DESE-bis implementation must not offer it and must reject it if received. The IANA PPP registry preserves that lineage today.

RFC 2419 also became Standards Track and sharpened its security language. It did not replace single DES with triple DES. PPP Triple-DES was separately specified in RFC 2420 and assigned ECP type 2. The replacement was principally a padding and interoperability correction, a new number to prevent silent cross-version confusion, and clearer editorial boundaries.

Export law left a line inside the protocol record

RFC 1969 describes DES as widely understood and implemented, then notes that compilation-ready source could not be included because US export laws forbade it. RFC 2419 retained the sentence two years later. The line is a documentary fossil from an era when publishing cryptographic software and publishing a protocol description were treated differently by export controls.

It supports a narrow historical claim: legal constraints shaped what this Internet document contained. It does not prove where any implementation was built, whether a particular product was exportable, or whether source elsewhere was lawful. The absence of code is part of the document’s provenance, not evidence of deployment or security.

The Datatracker history and RFC Editor records establish status and succession. The errata endpoint did not yield a usable body during capture, so no claim is made that the errata set is empty.

Five receipts, not one green light

A faithful operational record separates at least five observations. First comes the ECP configuration: direction, DESE type, nonce and the identity of the configured secret—not the secret itself. Second comes transport order: the observed 16-bit sequence and any gap. Third comes cryptographic state: the exact previous ciphertext tail used as C[0]. Fourth comes plaintext reconstruction and padding removal. Fifth comes PPP acceptance and upper-layer or application receipt under RFC 1661.

Only the first four belong to the DESE mechanism. A successful computation may still yield a frame rejected by padding or PPP. A PPP handoff may still lead to an application failure. Conversely, sequence discontinuity may correctly predict one unreadable successor without saying anything about the business consequence.

Heng Lu’s Running-Code Primacy supplies the discipline for reading these receipts: written state and observed operation must meet before a claim expands. Minimum Initial Specification argues for assigning a field only the authority its function requires. Reality Layers warns against promoting a symbol into an outcome, while Reality, Not Advocacy favours an account that reveals structure without inventing motives. These are editorial lenses, not sources for the protocol’s history.