Summary

  • RFC 3336 used AAL2 multiplexing to carry small PPP payloads efficiently, including traffic such as voice after RTP header compression.
  • The standard kept the trust boundary narrower than the shared ATM connection: PPP-session authentication did not secure neighboring non-PPP Channel Identifiers, nor the ATM switching fabric.

A shared bearer did not make a shared identity

The design problem began with a mismatch in scale. PPP over AAL5 worked well for carrying IP, but RFC 3336 said its padding and framing could waste bandwidth when the payloads were small—especially voice packets whose RTP headers had already been compressed. AAL2 offered another arrangement: its Common Part Sublayer could multiplex multiple PPP payloads into ATM cells rather than making each small packet bear the same whole-frame costs.

That efficiency did not turn an ATM virtual connection into one indivisible PPP link. RFC 3336 described the PPP/AAL2 service as a full-duplex, point-to-point virtual connection, either provisioned in advance or switched on demand. Inside it, the AAL2 Channel Identifier (CID) marked a substream. A PPP session could use one CID or several; endpoints had to agree on the count, the service-specific sublayer mapping, and the CID values. Provisioning could supply those choices for a dedicated connection; signaling could supply them for a switched one.

The distinction matters because the same virtual connection could also carry conventional AAL2 traffic and different service-specific convergence functions. A CID was a way to separate substreams, not a cryptographic identity. The document therefore drew a careful limit around PPP authentication: a peer’s successful PPP authentication and related mechanisms could not be assumed to secure non-PPP CIDs sharing that connection. Nor did PPP authentication secure the ATM switching network itself. If that transport infrastructure were compromised, RFC 3336 warned, a man-in-the-middle attack could still be possible.

There were additional receipts, but none collapsed those boundaries. Link Up or Down could be derived from type 3 fault-management packets in the relevant CID flow. The encapsulation also used a 16-bit CRC for error detection. Neither a link-state indication nor a CRC established who controlled a neighboring CID or protected its contents from an adversary. The standard pointed readers toward higher-layer authentication or encryption, and/or ATM-layer security services, where protection beyond the PPP session was required.

RFC 3337, published alongside it, shows why channel separation also attracted real-time designers: a PPP session could span multiple CIDs so fragments from different classes could be interleaved. But the companion document left the CPS scheduling method dependent on application requirements. A class identifier alone was not a latency guarantee. That is a useful historical boundary: the format made differentiated handling possible; it did not prove that a particular scheduler or network delivered it.

The claim here is deliberately limited to the design record. The RFC Editor lists RFC 3336 as a Proposed Standard, and the text specifies a mechanism. Neither fact establishes which vendors implemented it, how widely it was deployed, or whether any operator experienced a related security failure. Heng Lu’s Note 65 offers a fitting editorial discipline: read a standard as a proposal for running systems, not as proof that those systems adopted it.

The central lesson is architectural. Sharing a transport connection can reduce per-packet cost while leaving several distinct control and trust domains inside it. An operator or implementation review that sees “PPP authenticated” should ask what exactly was authenticated: the PPP peers and traffic governed by that session, or every CID, service-specific function, and switch traversed by the virtual connection? RFC 3336 answered that the first did not imply the second.

Sources

RFC Editor status page

Sources: RFC 3336 · RFC 3337 · PPP over AAL5, RFC 2364 · PPP Multiplexing, RFC 3153 · PPP, RFC 1661 · RTP header compression, RFC 2508 · Low-bitrate real-time links, RFC 2689 · ITU-T I.363.2 · ITU-T I.366.1 · Lu Heng, Note 65