要約

  • LACNICの登録APIページは、v3の最も新しい文書をPostmanで確認するよう案内する。しかし同じページの表は、ROAの変更と削除を/rpki/roas/{serialNumber}という個別経路で説明している。
  • 公開Postmanコレクションでは、GET、作成、更新がorganizationId単位で行われ、PUTは既存のROA一覧を更新版で置換する。確認した公開例には、基準版、条件付き書き込み、差分、事前確認が示されていない。
  • 一覧全体を望ましい状態として送る方式は、単純で原子的かつ冪等にできる。基準状態の識別子、意図した差分、preflight、原子的な結果と訂正関係を加えれば、その利点を保ったまま検証可能になる。

APIを実装する担当者は、まず案内に従う。LACNICの登録APIページは、v3について最も新しい文書がPostmanにあると説明する。実際、/lacnic/v3/infoへのアクセスは公開された同じ文書へ転送される。入口としての権威はPostmanに置かれている。

ところが、入口ページの表が描くROAは個別の記録である。作成と取得は/rpki/roas、変更と削除は/rpki/roas/{serialNumber}とされる。シリアル番号で対象を選び、その一件に命令する。ほかのROAは、その要求の外側に残る。

リンク先のAPI Registro v3 Prodでは単位が変わる。GETとPOSTは/lacnic/v3/rpki/roas/{organizationId}、PUTも同じ組織単位の経路を使う。説明は、既存の一覧を更新版で置き換えるとしている。失効はROAのリストを/lacnic/v3/rpki/roas-delete/{organizationId}へPOSTする。

これは表記ゆれではない。シリアル番号は一件の変更を表し、組織IDへのPUTは集合の最終状態を表す。集合には、含まれなかった項目まで意味を持ち得る。

全体置換を採る合理性

望ましい状態を一度に送る方式は、運用上よくできている。クライアントは現在一覧を読み、社内の意図と照合し、最終的に存在すべき一覧を作る。サーバーは全体を検証して一回で確定できる。個別の追加、変更、削除を順に実行し、途中で一つ失敗して半端な状態を残す危険を減らせる。

同じ一覧を再送しても、同じ結果に収束させやすい。応答だけが失われたとき、同じPUTを再試行して別の副作用を増やさずに済む設計も可能だ。IPAMや定期的な整合処理にとって、命令列より最終状態の方が扱いやすいことは多い。

LACNICが公開例の外側で競合を制御している可能性も十分にある。組織ごとに書き込みを直列化し、内部版を比較し、保護された監査記録を残し、認証後の画面で差分を見せているかもしれない。本調査は認証APIを呼んでおらず、ROAを作成、変更、失効させてもいない。公開文書に見えないことを、実装に存在しないと断定してはならない。

問うべきなのは狭い点である。公開された現在の契約だけで、クライアントは「この一覧は、私が読んだ状態がまだ現行である場合にだけ置換される」と確認できるだろうか。

古い一覧は、知らない変更を削除意思に変え得る

二つの正当な自動処理を考える。一方は、新しいプレフィックスのROAを追加するため一覧を読む。もう一方は、それより前に一覧を読み、別のROAのmaxLengthを修正しようとしている。それぞれのローカル状態では、完成した一覧に矛盾はない。

追加側が先にPUTした後、古い基準を持つ修正側が全体を送ったらどうなるか。サーバーは競合として拒否できる。書き込みを順番に処理して再読を求めることも、内部で差分を統合することもできる。あるいは後の一覧をそのまま採用することもできる。公開例は、この選択を説明していない。

調べた要求・応答欄には、ETag、If-Match、版トークン、基準一覧のハッシュ、compare-and-swapに相当する記述がなかった。dry-runやpreview、予定差分も示されない。GETの例は配列を返し、公開された応答ヘッダーはContent-Typeだけである。更新例には応答本文と応答ヘッダーが掲載されていない。

これは文書の観察であって、障害報告ではない。失われた更新、誤ったROA、経路漏えい、ハイジャック、停止、会員被害は確認されていない。むしろ、実装が安全であっても、その安全性を新しいクライアントが公開契約から再現できないことが問題となる。

ROAの一項目には、経路起源の権限が含まれる。RFC 9582は現在のROAプロファイルを定め、IPアドレス資源、起源AS、必要に応じて最大長を結び付ける。RFC 9319は、maxLengthがより具体的な経路の許可範囲にどう影響するかを説明する。

一覧からの脱落や最大長の変更は、検証側が参照する証拠を変え得る。ただし、LACNICがルーターの方針を決めるわけではない。リポジトリからの取得、検証結果の利用、経路選択はそれぞれ別の権限に属する。登録APIが証明すべきなのは、自分がどの状態を受け入れたかである。

三つの公開面を一つの定義から作る

最初の改善は、ウェブ表、/infoの転送先、Postmanコレクションを一つの版管理された定義から生成することである。現行の更新が組織一覧の置換なら、短い表にもそう書く。シリアル番号経路が現在も使えるなら、個別操作なのか、互換経路なのか、内部で集合操作へ変換されるのかを示す。

Postmanのメタデータには2023年6月の公開日があるが、最終更新日と確認されたものではない。取得時の版タグはlatestだった。日付の推測で権威を選ばせるのではなく、すべての面に同じ契約バージョンを表示するべきだ。

次に、GETが基準状態の識別子を返す。ETag、正規化一覧のハッシュ、不透明なリビジョンなどが考えられる。PUTはその値を添え、「現在一覧がこの基準のままなら置換する」と宣言する。変わっていれば、サーバーは何も変更せず競合を返す。

その前にpreflightを置く。追加、変更、削除を、プレフィックス、起源AS、maxLengthとともに列挙する。クライアントの不完全なシリアライズで項目が消えたのか、明示的に失効させたいのかを、確定前に見分けられる。構文検証だけでなく、基準の古さもここで判定する。

結果には一つの操作IDを与える。契約版、受け入れた基準、結果の状態識別子、成功または拒否を記録する。タイムアウト後の再試行は同じIDで結果を確認できる。後の訂正は前の操作を指し、現在値で履歴を塗り替えない。

公開契約の要素 明らかにすること
経路・スキーマ版 どの書き込み規則が実行されたか
組織と基準一覧ID どの観測状態に意図が基づくか
追加・変更・削除の差分 完全なpayloadが何を変えるか
preflight 検証エラーと古い基準を事前に止めたか
原子的操作と結果ID 一連の遷移が受理、拒否、再確認のどれか
訂正リンク 後の判断が何を置き換えたか

個人名、APIキー、内部の不正防止規則を公開する必要はない。スキーマと保証は公にし、詳細な受領記録は権限を持つ組織に渡せばよい。これは統治を厚くする提案ではなく、実行された最小の状態遷移を証拠にする提案である。

LACNICは、誤ったROAを直し、保守を自動化できる環境を提供している。その成果を否定せずに、次の境界を明瞭にできる。案内板が一件を指し、実行文書が全体を指す状態を解消し、全体を置き換えるなら何を基準にした全体かを要求する。それだけで自動化は、速いだけでなく停止すべき時に停止できる。

出典