要約

  • ARINのACSP 2023.1によれば、XML APIで自動更新されたAS13335:AS-CUSTOMERSは、生成されたRPSLで多数のメンバーが一本の物理的なmembers:行に置かれていた。
  • 提案者は、IRRd v3だと考えたミラーへの再帰問い合わせを示し、完全なプロトコル応答は7個のASNだけだった。ARINは一行当たりの項目数を抑えれば問い合わせ結果が改善すると認め、実装まで提案をOpenにすると答えた。
  • 論理メンバー集合、RPSL属性、出力バイト、ミラー取り込み、保存済みオブジェクト、再帰結果、生成フィルターは別々の状態である。最初が有効でも後段の完全性は証明されない。
  • ミラー間直列化レシートは、正規化メンバー数とダイジェストを、正確なRPSLバイト、行境界、取り込み識別子、解析後の件数、問い合わせ結果のダイジェストに結び付け、拒否や切り詰めを明示すべきである。

7個という答えから上流をたどる

ARIN ACSP 2023.1で、Joe AbleyはCloudflareがXMLペイロードを用いてAS13335:AS-CUSTOMERSを自動公開していたと説明した。ARINが作成したRPSLでは、多数のASNが一つのmembers:行に連結されていた。

公開ページは長い列の冒頭と末尾を示し、中間を「さらに多数」と省略する。したがって、現在そのページだけから完全な件数やダイジェストを再構成することはできない。それでも、当時の物理表現が一行に集中していたという証拠にはなる。

提案には、別のミラーに対する!iAS-CLOUDFLARE,1の出力も残る。提案者はそのサーバーをIRRd v3だと思う、と限定している。応答は7個のASNと終了記号で完結しており、単なる画面上の省略ではないとされた。本稿はそのミラーを再試験しておらず、現在も存在するとも同じ挙動をするとも主張しない。

ARINは2023年2月7日、一行の項目数を制限すればAS-SET問い合わせの結果が良くなると回答した。要件を調査し、将来の開発に組み込み、実装まで提案をOpenのままにするとした。現在もページはOpenだが、これは公開チケットの状態である。現在のARIN出力が2023年と同一だという証明にはならない。

同様に、現在のCloudflareの集合、フィルター、BGP公告が誤っている証拠でもない。経路漏洩、障害、ハイジャックの発生も示していない。確実に言えるのは、豊富な元表現と非常に短い派生回答の不一致が記録され、ARIN自身が行分割による結果改善を認めたことである。

論理集合と物理行を混同しない

RFC 2622では、AS-SETのmembersは任意かつ複数値を持てる属性で、値はASNまたは別のAS-SET名のリストである。リストであることと、同名属性を複数回記述できることは別の性質だ。

テキスト表現にはさらに行の規則がある。属性と値の組は物理行から始まり、次の行の先頭が空白、タブ、またはプラス記号なら値を継続できる。members:自体を複数回書くこともできる。そのため、同一の論理集合が、一つの長い行、複数の属性、あるいは継続行として表現され得る。意味が同じでも、バイト列、行数、最大行長は異なる。

通常は整形上の違いに見えるが、独立した実装をまたぐと互換性条件になる。新しいパーサーが数キロバイトの行を読めても、古い読み取り部は短いバッファやフィールド長を前提にするかもしれない。通信が全バイトを届けても、インポーターが値の後半を失うことがある。更新失敗後に旧版を残す実装もあり得る。

ACSP記録は正確な原因を特定していない。特定のバッファやIRRdの欠陥と断言するのは証拠を越える。必要なのは、物理直列化自体を測定対象にすることだ。

XMLからRPSLへの変換も運用インターフェースである

ARINの現行IRR概要は、XMLで送られたシンプルオブジェクトをバックエンドでRPSLへ変換すると説明する。REST APIガイドはXMLとRPSLの表現を扱い、membersを集合に属するASNまたはAS-SETとして定義する。

発行者は論理メンバーを決める。ARINはXMLをどの物理RPSLへ変えるかを決める。歴史的提案によれば、XMLスキーマから一行当たりの要素数を指定できず、その選択はARINの生成コードにあった。

行を短くするのは合理的な緩和策である。古い入力処理の限界を踏みにくくできる。しかし、改行だけで完全性は証明できない。画面表示だけが折り返し、実際のエクスポートは長いままかもしれない。ミラーが全行を受け取っても、別のメンバー数制限を適用するかもしれない。オブジェクトが完全でも、ソース選択や再帰規則により結果が変わり得る。

したがって、試験は正規化した集合と正確なバイトの双方を比較しなければならない。

ミラーで証拠の管理主体が変わる

ARINは現在、NRTM、データベースファイル、Whoisを提供し、現行サーバーをIRRd Version 4としている。IRRdのミラー文書では、スナップショットまたは差分を取得し、解析・検証してローカルデータベースへ書き込む流れが示される。

ミラーは透明な窓ではない。ソフトウェア版、設定、ソース方針、取り込み履歴、エラー処理を持つ別システムである。元が完全に公開したことは、ミラーが完全に保存したことを意味しない。保存が完全でも、問い合わせが同じソースと深さで展開したとは限らない。

最低でも三つの接続を検査する必要がある。出力バイトと受信バイトは一致したか。正規化メンバー集合は保存後も一致したか。その保存状態から、明示した問い合わせ条件で期待結果が得られたか。中間比較がなければ、短い回答が通信、取り込み、解析、再帰のどこで生じたか判断できない。

現行IRRdのトランザクション型ロードは、利用者に取り込み途中を見せないために有効である。ただし、原子的に確定した状態が意味的にも完全だとは限らない。また、現在のIRRd仕様から2023年の旧ミラーを推定してはならない。

再帰結果はローカルグラフの計算結果

IRRdのWhois問い合わせ文書は、!iを処理済みデータを返す問い合わせとして説明する。再帰を指定すると入れ子集合をたどり、解決したメンバーを空白区切りで返す。元のRPSLテキストではない。

ローカルオブジェクトを直接読むと、ミラーが何を保存したか分かる。再帰問い合わせは、そのオブジェクトグラフが何を導出するかを示す。フィルター生成器はさらにASNからプレフィックスを求め、設定を構築する。各段階は前段を利用するが、同じ成果物ではない。

正常終了した短い回答は、明示エラーより危険になり得る。自動処理が成功と解釈し、欠落をそのまま次段へ渡すからだ。必要なのは成功コードだけでなく、期待した集合との完全性照合である。

意味とバイトを結ぶレシート

ミラー間直列化レシートによって、この境界を監査可能にできる。これは本稿の提案であり、ARIN、IRRd、Cloudflareの既存計画ではない。

発行側はAS-SETキー、オブジェクト版または公開シリアル、公開された正規化規則によるメンバー数とダイジェストを記録する。続いて、シリアライザー名と版、正確なRPSLバイトのダイジェスト、総バイト数、物理行数、最大行長を残す。

ミラー側はソース、スナップショットまたはNRTMシリアル範囲、取り込み時刻、パーサー版と結果を記す。受信バイトの一致を確認し、保存オブジェクトのダイジェスト、解析メンバー数、正規化メンバーダイジェストを残す。状態は完全、拒否、切り詰め、部分解析、失敗後の旧版維持を区別する。

問い合わせ時には、文字列、ソース選択、再帰フラグまたは深さ、除外集合、実行時刻、結果数、結果ダイジェストを追加する。下流のフィルター生成器は、機密設定を公開せずに成果物ダイジェストを関連付けられる。

この仕組みはソフトウェアや経路判断を一元化しない。同じ意味を運ぶはずの表現が、どの境界で初めて一致しなくなったかを見えるようにする。

出典