要約

  • RFC 3336はAAL2の多重化を用い、RTPヘッダー圧縮後の音声など、小さなPPPペイロードを効率よく運ぶ方式を定めた。
  • 共有ATM仮想接続より信頼境界は狭い。PPPセッションの認証は、隣接する非PPPのCIDやATM交換網まで保護しない。

CIDは認証情報ではない

出発点は、パケットの大きさとカプセル化のコストのずれだった。PPP over AAL5はIPを運ぶ用途には適していたが、RFC 3336は、小さなペイロードではパディングやフレーミングが帯域を無駄にし、とりわけRTPヘッダーを圧縮した音声で問題になると説明した。AAL2なら、共通部サブレイヤ（CPS）が複数のPPPペイロードをATMセルへ多重化できる。短いパケットごとに同じフレームコストを負わせない構成である。

ただし、それでATM仮想接続全体が一つのPPPリンクになるわけではない。RFC 3336が描くPPP/AAL2サービスは、全二重のポイントツーポイント仮想接続で、事前にプロビジョニングする専用接続にも、要求時に確立する交換接続にもなり得る。その内部でAAL2のチャネル識別子（CID）がサブストリームを区別する。一つのPPPセッションにCIDを一つ割り当てることも、複数を使うこともできるが、両端はCIDの数、サービス固有サブレイヤとの対応、値をあらかじめ合意しなければならない。専用接続なら設定、交換接続ならシグナリングがその合意を運ぶ。

同じ仮想接続には、通常のAAL2トラフィックや異なるサービス固有コンバージェンス機能も共存できた。CIDはサブストリームを分けるもので、暗号学的な身元証明ではない。RFC 3336はここで明確な境界を引く。PPPセッションの認証や関連機構が成功しても、同じ接続上にある非PPPのCIDまで保護されていると仮定してはならない。また、PPP認証はATM交換網そのものを守らない。伝送網が侵害されれば、中間者攻撃の余地があると同文書は警告した。

リンクのUp/Down状態は、該当CIDフロー内のタイプ3障害管理パケットから導ける、と規格は定めた。カプセル化には誤り検出用の16ビットCRCもあった。しかし、リンク状態の通知もCRCも、隣のCIDを誰が制御するかを証明せず、その内容を攻撃者から隠すものでもない。PPPセッションを越える保護が必要なら、より上位の層での認証や暗号化、あるいはATM層のセキュリティ機能を別に考えるようRFC 3336は促している。

同時期のRFC 3337は、複数CIDがリアルタイム通信にも役立つ理由を示す。一つのPPPセッションを複数CIDにまたがらせ、異なるクラスのフラグメントを交互に送れるからだ。ただし、CPSのスケジューラー方式はアプリケーション要件に委ねられた。クラス識別子があるだけで遅延が保証されるわけではない。規格が可能にしたことと、実際のネットワークで提供されたことは別である。

ここで言えるのは文書上の範囲に限られる。RFC EditorはRFC 3336をProposed Standardとして掲載しているが、それは仕組みの仕様を示すにすぎない。どのベンダーが実装したか、どれほど普及したか、これに関係する事故があったかまでは証明しない。Lu HengのNote 65にある考え方を借りれば、規格は稼働システムへの提案であって、採用の証拠ではない。

残る教訓は設計上のものだ。伝送接続の共有はパケット当たりのコストを下げても、その内部に複数の制御・信頼領域を残し得る。「PPP認証済み」と記録されていたら、何が認証されたのかを問う必要がある。PPPの両端とそのセッションの通信なのか、それとも仮想接続上の全CID、全サービス機能、全スイッチなのか。RFC 3336が示したのは、前者から後者を推論できないという境界だった。

出典

RFC Editorのステータス情報

出典：RFC 3336 · RFC 3337 · PPP over AAL5, RFC 2364 · PPP Multiplexing, RFC 3153 · PPP, RFC 1661 · RTPヘッダー圧縮, RFC 2508 · 低速リンクのリアルタイム通信, RFC 2689 · ITU-T I.363.2 · ITU-T I.366.1 · Lu Heng, Note 65