要約

  • RFC 2516 は、セッション状態を持たない探索段階とポイントツーポイント PPP セッションを分けた。仮想インターフェース資源を割り当てるのは、セッション成立後の両端である。
  • 任意の AC-Cookie は、アクセス集約装置が送った値を送信元アドレスから返せるかを確認する。Host-Uniq と Relay-Session-Id は、それぞれホストと中継者が所有する別の相関情報だった。
  • これらの不透明なタグが表すのは限定されたパケット文脈である。個人認証でも、その後の PPP 設定、通信、商用サービスの証明でもない。

セッション表を作らずにブロードキャストする

1999年2月の RFC 2516 は、複数のホストとアクセス集約装置が共有する Ethernet 上で PPP を運ぶ方法を記した。ホストは PADI をブロードキャストし、応答可能な集約装置は PADO を返す。ホストはその一つを選び、PADR を宛先指定で送り、PADS で受理されたサービスとセッション識別子を受け取る。RFC は Discovery と PPP Session を明確に分け、PPP セッション成立までは Discovery をセッション状態なしで保つ。成立後はホストと集約装置の双方が PPP 仮想インターフェース用の資源を割り当てなければならない。

この境界により、共有 Ethernet に見える各要求が直ちに持続的なセッション資源へ変わることを避けた。「状態なし」はパケット処理に計算資源が一切不要という意味ではない。選択された相手との PPP セッション状態をいつ確保するかを定めている。

値は往復できなければならない

集約装置は任意の AC-Cookie を PADO に含められる。受け取ったホストは値を解釈せず、PADR にそのまま戻す。RFC は集約装置が PADR の送信元アドレスから値を再生成できることを推奨した。これにより、オファーを受けたアドレスに戻り経路があるかを確認し、そのアドレスの同時セッション数を制限できる。

RFC は集約装置だけが知る鍵でホストの MAC アドレスに HMAC を計算する例を挙げるが、方式は指定していない。Cookie がすべてのサービス妨害攻撃を防ぐわけではないことも明記している。ここでの狙いは戻ってきた値を見てからセッション資源を約束することであり、アドレスの背後にいる人物を特定することではない。

タグごとに所有者も異なる。ホストが選ぶ Host-Uniq は受信した PADO や PADS を自分の要求と対応づけ、集約装置は値を解釈せずそのまま返す。中継者が追加しうる Relay-Session-Id は両端にとって不透明で、応答でも変更せず返される。相関の成功は身元の証明に変わらない。

PADS で資源状態が変わる

受理された PADS はゼロでない SESSION_ID とサービス名を含み、サービス名の拒否はエラータグと ID ゼロで表す。セッションは送信元 MAC、宛先 MAC、SESSION_ID の組で定義され、16ビットの番号だけでは識別できない。

PADS は PPP Session 段階への移行を示すが、RFC 1661 が定める LCP 交渉、任意の認証、ネットワーク制御プロトコルによる設定を代行しない。本稿は隣接する RFC 4638 が扱うペイロードサイズや1492バイトの境界を繰り返さず、資源割り当ての時点とタグの射程を扱う。後続サービスが届いたかどうかを主題にしていない。

RFC 2516 が記録するのは資源保護の設計と明示された限界であり、節約できるメモリー量、現代の普及状況、個別セッションの認証・通信実績ではない。

出典： RFC 2516、RFC 1661、RFC 2104、RFC 4638（ペイロードサイズの隣接論点。ここでは対象外）。