要約
- RFC 5393は、十個未満の正当なSIPメッセージから潜在的に
2^71へ広がる木を示した。複数AOR版では全プロキシがループ検出しても、反復前の異なる経路がN!を超える。 - Max-Breadthは未完了の同時分岐を予算内に収める一方、最終応答後に許可を再利用する。ピークは下がるが、RFC自身が総トラフィックは減らないと明記している。
- 登録グラフ、Via履歴、ループかスパイラルかの判定、同時数、累積分岐、B2BUAを越えた履歴は別々の証拠である。
許可証は使い切りではなかった
応答コンテキストには Incoming Max-Breadth と Outgoing Max-Breadth がある。後者は、転送済みでまだ最終応答を受けていない要求に割り当てた値の合計であり、前者を超えてはならない。
最終応答が来ると、その枝は合計から外れ、値を再利用できる。八宛先、予算四なら、四本を開始し、失敗ごとに残りを一本ずつ開ける。並列制限は完全に守られながら、生涯の試行数は八になる。
再利用しない案も検討された。その案なら、一つの根要求が作るトランザクション数を初期値の定数倍に抑えられた。しかし正当な到達範囲を大きく変え、既存運用を壊す恐れがあるとして退けられた。標準はピーク保護と逐次到達を両立させ、総量の判断を運用へ残した。
したがって「上限四」という説明だけでは足りない。同時四本、全期間四本、四ホップ、四AORは別物である。RFC 5393が保証するのは最初だけだ。
正当な登録が二分木を作った
単純な攻撃では、二つのproxy/registrarに四つのAORがある。P1側の各AORはP2側の二つをContactに持ち、P2側もP1へ同じ設定を持つ。一つのINVITEは二本、四本、八本へ分岐する。
各REGISTERは正当でもよい。増幅は個々の構文ではなく、解決関係の合成から生まれる。Max-Forwardsがゼロになるまで続き、推奨初期値70なら木は2^71 - 1要求を含む。処理がTimer Cを超えれば408やCANCELも重なる。
RFCはSIPitでの実演も記録する。Max-Forwardsを20に下げ、二台より多いプロキシを使っても、相互送信は数時間続いた。完了は十日弱と推定された。登録状態を維持した機器は再起動後に再び参加した。
新しいプロセスは新しい原因ではない。永続した登録グラフが同じ実行権を残すなら、再起動は仕事を再開するだけである。
反復検出は未出の順列を止めない
単純な往復にはループ検出が効く。全プロキシが実施すれば、RFCの最初の例は14メッセージ、単一サーバー版は10に縮む。そのため複数宛先へforkするプロキシには、同じ処理状態へ戻っていないかの確認が求められた。
Viaのbranch値の第二部分はRequest-URI、使用したRoute、そのほか転送判断に影響する入力に依存する。再訪時に同じ値ならループとして482を返す。異なるなら、経路条件が変わったスパイラルとして続行できる。
ここで必要なのは履歴である。途中の装置がVia値を削除・変更・難読化すれば、元のプロキシは自分の過去を照合できない。二つの装置がそれを行えば、双方が共同で消した循環を双方とも見つけられない。
さらにN個のAORを相互に全接続すると、反復が現れる前にN-1個の全順列を通れる。各経路の末端がN本へ分岐するため、その層だけでN!要求になる。RFCの表では四AORで64、六で1,956、八で109,600、十で9,864,100である。
これは一般的なトラフィック予測ではない。ループ検出が「同じ過去」を止めても、初めて現れる異なる過去の数を上限化しないことを示す。
距離、同時数、累積数を混ぜない
Max-Forwardsは距離を制限する。Max-Breadthは同時幅を制限する。RFCは幅を各ホップで減算し、距離制限として使うことを禁じる。累積分岐はさらに別の軸である。
440 Max-Breadth Exceededも総作業停止の証明ではない。希望する並列forkを予算内で行えず、逐次化もリダイレクトもしない場合の応答だ。値1でも逐次forkは可能である。
セキュリティ節は、Max-Breadthが攻撃の総トラフィックを減らさず、長い時間へ広げるだけだと述べる。複数の根要求を入れれば、各根が遵守しても未完了トランザクションを不合理な水準へ積める。
得られるのは介入時間だ。AOR別と全体の未完了数を監視し、原因資源を一時停止できれば、ピークを抑えた意味がある。監視がなければ、遅い増幅は発見しにくい増幅になる。
B2BUAの境界で過去が切れる
B2BUAはUAS側で要求を終え、UAC側で新しい要求を作る。トポロジーを隠す理由があっても、Viaや上限値を捨てれば、分散防御が依存する連続履歴も失われる。RFC 5393は、二つの境界が履歴を消すと、Max-Forwards、ループ検出、Max-Breadthのどれも十分に働かない場合を警告した。
RFC 7332は後に、B2BUAがMax-Forwardsをコピーして減算し、Max-Breadthをコピーして実施することを要求し、RFC 5393方式のループ検出を推奨した。同時に、難読化とループ検出の緊張も明示した。
規格発行は実装証明ではない。稼働コード優先の原則に従えば、実際のB2BUAを横断する要求を流し、両側の値、履歴、生成分岐を観測する必要がある。
証拠の境界
凍結した資料はRFC本文、そこに記されたSIPit実演、計算と要件を裏づける。現在の製品採用、攻撃頻度、障害原因は裏づけない。2^71、N!、9,864,100には必ず前提を付ける。
結論は一つだ。同時分岐数は写真であり、総仕事量は台帳である。安全を主張するなら、両方と、返却された許可を次に使った決定を保存しなければならない。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
