要約

  • 10月2日付のGROW作業部会草案 draft-ietf-grow-routing-ops-sec-inform-03 は、設定の適用方式に関する節を新設した。複数の変更を準備して原子的に確定する方式と、一行ずつ直ちに実行する方式を区別する。文書はまだInternet-Draftであり、承認済みRFCではない。
  • 例では、route-mapの action permit が先に有効になり、後から set large-community add 65536:0:0 を加える。上流から学習した経路を拒む規則より前にその許可規則があれば、設定途中にピアへ経路が漏れ得る。実際の事故を報告したものではない。

変更作業の承認で「完成した設定が正しいか」だけを尋ねると、装置が実際に通った状態を見落とす。GROWの草案第03版が追加したのは、まさにその途中の扱いだ。Datatracker上では作業部会の有効な草案で、IESG状態は I-D Exists、予定する分類はInformationalである。文書自身も、世界的な経路制御の安全策を網羅したり、各手法の効果を採点したり、特定の実装を命じたりするものではないと断っている。

新設の「Impact of the Configuration Paradigm」は、設定の確定点を問題にする。トランザクション方式では複数の編集を準備し、まとめて反映できる。一方、コマンド即時実行方式なら最初の一行が本番の振る舞いを変える。草案の例は、route-mapでまず action permit を入力し、その後にLarge Community 65536:0:0 を付加するというものだ。上流から得た経路を拒む規則より前にこの許可が置かれると、完成前の規則が対等接続先への広告を許してしまい得る。Communityの値自体が送信者の権限を証明するわけではない。

ただし、非原子的な変更への警告そのものが今回初めて現れたわけではない。第02版はプレフィックスフィルター変更の整合性を論じ、一時的に望ましくないプレフィックスを通したり、中断後に矛盾したポリシーを残したりする可能性をすでに記していた。第03版の違いは、これを設定方式一般の論点に広げ、許可規則の実行順序を具体化したことにある。草案は運用者が方式の違いを理解するよう求めるが、あらゆる装置に共通する切替手順を定めてはいない。

RFC 8212を「誤った広告は起こり得ない」という保証に使うのも違う。同RFCはEBGPの輸入・輸出に明示的なポリシーを要求し、ポリシーがなければ拒否する。しかし、誤った明示的設定からは守れないと明記する。途中で有効になったpermitは、まさに明示的な設定だ。最後にrejectが残っていることと、作業中に隣接ピアが不要なUPDATEを一度も受け取らなかったことは別の事実である。

作業を検証するなら、装置がコマンドを受理した記録、意図した完全なポリシーが適用された記録、ピアが許可された経路だけを受け取った記録を混同しないことだ。完成版の差分は主として二番目を示す。代替ポリシーを先に完成させて参照を切り替える案も、装置が許す場合の候補にはなる。ただし参照切替そのものが原子的かどうかは別途試験が要る。これらは草案の失敗例から導く運用上の提案で、IETFが新たに強制した監視項目ではない。

参照した一次資料は特定のネットワークで漏洩が起きたこと、特定製品の欠陥、発生率を示していない。だからこそ論点は明確だ。審査すべき対象は静的な完成形だけでなく、経路が外へ出得る各中間状態である。

出典