要約
- IESGは8月28日、Best Current Practiceを目指す
draft-ietf-sidrops-publication-server-bcp-10をLast Callに付した。Datatracker上の期限は9月11日である。 - 草案はBCP 14の
MUSTやSHOULDを用いる一方、それらは運用上の重要性を強調するもので、正式な実装要件ではないと注記する。 - 最終的にBCPとなっても、個別のRIR、NIR、CA、公開事業者、CDNが各項目を実装したことや、障害時に守ったことまでは証明しない。
- 必要なのは認証バッジではなく、章ごとの実装記録である。文書版、構成、状態、例外、測定窓、復元、RRDPセッション変更、通知、再同期、外部観測を結ぶ。
- Last Callは採択ではなく、著者の所属は監査結果でもない。IETFの合意は契約、規制、購買保証、各ネットワークの経路方針を置き換えない。
署名の後ろにある運用面
RPKIオブジェクトは署名された瞬間に世界中の検証者へ届くわけではない。CAが証明書やROA、ASPAなどを作成し、RFC 8181の公開エンジンへ変更を送る。公開側ではRRDPとrsyncがリポジトリの状態を提供し、relying partyが取得・検証する。その後で初めて、ネットワークがローカル方針に利用する。
8月28日にLast Callが始まった版10は、この公開区間を対象とする。文書は、CA側エンジンと公開取得面の分離、高可用性、データ損失からの復旧、発行者との同期、DNSと経路への依存、IPv4とIPv6、CDNキャッシュ、RRDPのsnapshotとdelta、負荷分散、rsyncの一貫した読み取りを扱う。
運用上の失敗は一色ではない。正しく署名されたROAが公開エンジンに届かないことがある。エンジンの応答後も、一部の公開ノードが古い状態を返すことがある。古いバックアップから復元すれば、ファイル群は内部的に整っていても発行者の最新意図から後退する。通知ファイルだけが先に見えれば、そこに書かれたsnapshotやdeltaを取得できない。
署名は真正性と改変の有無に強い。配布時刻、鮮度、複数ノードの一致、復旧後の完全性は別の証拠を要する。草案はその違いを運用項目へ分解した。
「MUST」の直後に置かれた但し書き
RFC 2119ではMUSTは仕様上の絶対要件、SHOULDは例外の影響を十分理解したうえでのみ外れ得る推奨を表す。RFC 8174は、この特別な意味が大文字表記に限られることを明確にした。
今回の草案も同じ定型句を使う。ただし次の注記で、これらの語は運用の重要性を強調するためであり、正式な実装要件として求めるものではないと説明する。
片方だけを読むと意味を誤る。大文字だけを抜き出せば、IETFが適合試験や免許制度を作ったように見える。但し書きだけを強調すれば、重大な運用項目を任意の飾りへ落としてしまう。文書が定めるのは、強く支持された実務である。個別事業者を審査したという結論ではない。
RFC 7841が示すRFCのカテゴリとstatus boilerplateは、文書の出所、審査、合意を説明する。将来この文書がBCPとして公開されれば、その来歴は重い。しかし、それだけでは対象システム、監査期間、測定方法、例外、復旧試験、契約上の救済を特定できない。
合意は「何が良い実務か」を定義できる。「誰が実行したか」は別の記録でしか分からない。
可用性を一つの数字にしない
草案は公開コンテンツと公開エンジンの双方に高可用性を求めるが、停止時の影響は異なる。
発行者向けエンジンが止まると、新しい発行や失効を配布できない。長引けばmanifest、CRL、署名オブジェクトがstaleになる。RRDPやrsyncが止まると、relying partyが現在の状態を通常どおり取得できない。短い停止は有効なキャッシュで吸収される場合もあるため、単なる応答率では鮮度の残り時間を表せない。
少なくとも三つの分母が要る。エンジンへの書き込み、RRDP取得、rsync取得である。RPKI availabilityという一つの割合にすると、どの権能が失われたのか分からない。
草案は、公開エンジンを公衆向けRRDP・rsyncサーバーから分離するよう勧める。読み取り負荷が発行者の変更経路を止めないためだ。また、再発行したオブジェクトの期待出現時刻と実際の観測時刻を比べるround-trip監視を勧める。
この測定には、対象オブジェクト、開始イベント、終了観測、観測地点、期間、percentile、失敗、除外を明記する必要がある。草案が引用する研究の15～95分という範囲は、対象となったCAとリポジトリの結果であって、全サービスのSLAではない。
復元は「元に戻った」だけでは完了しない
バックアップ復元でコンテンツが後退した場合、草案はRRDP session resetを求める。依存するCAにも早く知らせ、完全な再同期を始められるようにすべきだとする。
ここには複数の時刻がある。復元したバックアップの時点、後退の検知、session_idの変更、発行者通知、RFC 8181 list queryによる比較、完全状態の再送、公開側での最終確認である。どれか一つを成功と呼んでも、残りは証明されない。
草案はCAに対し、変更送信前にサーバーの認識状態をlist queryで確認するよう勧める。原子的に反映したい変更群は一つのmulti-element queryにまとめる。変更がなくても定期照合は可能だが、RFC 8181には十分なrate limitやbackoff通知がないため、合意がなければ10分より頻繁に行わないよう求める。
運用記録は、復元、後退、RRDP再開始、通知、照合、再発行、外部確認を一つの因果列にする必要がある。月間稼働率はこの列を再現できない。
serialとmanifestが証明する範囲
RRDPのsession_idとserialは、relying partyがdeltaを続けて取れるか、snapshotからやり直すべきかを判断する手掛かりになる。不可変ファイルはキャッシュにも向く。これは配布の重要な仕組みである。
一方、serialが増えたことは、そのセッションで新しいrevisionが見えたという事実にとどまる。発行者が意図した全集の受理、全backendの同一視点、全relying partyの取得までは示さない。草案が、notificationを参照先のsnapshotとdeltaより先に公開してはならないとするのは、そのためだ。負荷分散下でも一貫したビューが必要になる。
RFC 9286のmanifestはファイル名とhashを署名付きで列挙し、古い版への置換、無断削除、転送中の改変など所定の結果を検知しやすくする。ただし、保守通知、dual-stack到達性、バックアップの新しさ、CDN設定、発行者支援を監査するものではない。
BCP準拠という一語でserial、manifest、到達性、復旧をまとめれば、証拠の境界が消える。章、版、測定窓、観測者を明示して初めて、その主張は検証可能になる。
集約推奨は独占権ではない
草案は、自己運用リポジトリが大規模な専門組織のサービスより可用性問題を起こしやすいという実務経験を挙げる。公開点が増えるほどrelying partyの負荷も増えるため、親CAが子CAへ公開サービスを提供し、子は利用可能ならそれを使うよう勧める。親が提供しない場合は、信頼できる第三者の利用も選択肢になる。
これは規模と運用効率の判断であり、RIR、NIR、企業へ政治的権限や排他的フランチャイズを与える条項ではない。更新が少ない小規模リポジトリなら、控えめな設備でも高可用性を得られることも文書は認める。
アドレスとASの配置にも同じ慎重さがある。リポジトリ自身でしか修復情報を公開できない権限へ全面依存すると、到達不能が自己修復を妨げる恐れがある。しかし他組織のアドレスやASへ移れば、別の依存が生まれる。正解は全員同じ構成ではなく、選択、責任主体、脅威想定、最後の試験を記録することだ。
自己運用、親運用、第三者、proxyのどれかを最初に示せば、各項目を実装済み、非該当、計画中、例外、不明に分けられる。理由付きの非該当は正確な情報である。無範囲の全面適合は情報ではない。
実装記録の最小構成
第一に、サービスの同一性を固定する。運用者、構成方式、公開識別子、対象顧客、参照するdraftまたはRFCの版を記す。
第二に、重要な各節を一行にする。状態、判断者、確認日、適用範囲、例外理由を残す。鍵、認証情報、非公開の発行者、攻撃に使える詳細構成は公開対象外とする。
第三に、証拠の定義を置く。エンジン、RRDP、rsyncの可用性を分離し、オブジェクト出現の起点と終点を定義する。notification cacheの規則と観測、backend間の安全な整合試験、失敗と除外を含める。
第四に、変更と事故を追う。保守、データ後退、session reset、発行者通知、再同期、完了確認、未解決差分を時系列にする。訂正は上書きせず新revisionとして加える。
最後に証拠の出所を書く。自己申告、外部計測、契約監査、事故レビューでは重みが違う。対象期間とシステムも明示する。将来正式な制度ができない限り、「IETF認証済み」とは書けない。
この記録は経路到達を保証しない。何を主張したかを狭くし、検証できるようにする。
現時点で言えないこと
Last Callは採択ではない。コメント後に文書が変わる可能性があり、IESGの評価も残っている。RFC番号もBCP番号もまだない。
著者の所属は所属組織の実装証明ではない。RIPE NCC、ARIN、APNICその他の組織について、全項目を実施した、または違反したという資料はない。隠された障害や失敗した復旧を示す証拠もない。
将来のBCPが、サービス契約、調達要件、法的命令、ローカル経路方針を自動的に上書きするとも書かれていない。
確実なのは、RPKI公開運用について詳細な候補実務が審議段階に入ったことだ。文書が強くなっても、サービスの現実はサービス自身の証拠でしか確かめられない。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加