要約
- GAAP-25は暗号化Claimに機密性と完全性を求め、ChaCha20単独の利用を禁じたが、Markerが示すのは暗号化の有無であり、送信者の身元や割当権限ではない。
- 鍵を持つノードと持たないノードは互いのClaimを見失い、別々の衝突空間を形成し得る。認証に成功しても、見えていない利用者がいないことや正当な保有を証明したことにはならない。
暗号化は普通、見えなくするために使われる。GAAPでは、その性質が予想外の場所に現れる。ある集団にとって安全に読めるClaimは、別の集団にとって存在しないClaimと同じである。両者が同じ物理ネットワークにいても、同じアドレスの衝突を別々の現実として判断できてしまう。
GAAPドラフト第25版は、管理ドメイン内でマルチキャストアドレスを軽量に調整する実験的な仕組みを記述する。Group Nameをハッシュして候補アドレスを作り、異なる名前が同じアドレスを選んだ場合は衝突とする。名称に1、2、3を加えた最大三つの候補へ移ることもできる。最初のClaimを送った後、およそ一周期待ち、その後は周期的なClaimでソフトステートを保つ。解放用のメッセージはなく、送信をやめればよい。
この文章を実運用の証明として扱ってはならない。IETF Datatrackerでは、Experimentalを意図したInternet-DraftとしてIESG EvaluationのAD Followup段階にある。履歴は仕様の更新を示すが、導入実績ではない。ドラフト自身も、分散型ハッシュ方式は未導入であり、衝突率や規模拡大時の挙動は測定されていないと明記する。
第25版が閉じた脆弱性
第23版から第25版への重要な変化は、暗号化を機密性だけで済ませないことだ。暗号化されたClaimは、AEADのように機密性と完全性の両方を提供しなければならない。ChaCha20単独は使ってはならない。RFC 8439が示す通り、ChaCha20はChaCha20-Poly1305を構成する暗号部分であり、単独では改ざんを検出しない。ストリーム暗号の可塑性を悪用すれば、復号後のアドレス、時刻、Group Nameに狙った変化を生じさせ得る。
同じ鍵を使うすべての送信者間でnonceを一意にすること、鍵を設定した受信者が平文Claimを拒否することも要求される。後者は、保護モードから無認証モードへの黙示的なダウングレードを防ぐ。
ただし、Markerは証明書ではない。暗号化されたレコードであることを暗示するだけで、アルゴリズム、公開された身元、権限の由来を運ばない。方式、鍵、レコード構造、associated data、nonce設計、動的な鍵更新の多くは帯域外で決める。復号に失敗した受信者はレコードを捨てるため、鍵違い、方式不一致、偶発破損、攻撃による変更が、いずれも「何も見えない」という結果になり得る。
正しいClaimでも、正当なClaimとは限らない
鍵付きノードは平文を拒否し、鍵なしノードは暗号文を理解できない。その結果、二つの集団が互いを無視したまま同じアドレスを選べる。さらに同じ鍵を持つ集団の中でも、悪意ある参加者は認証に合格するClaimを作れる。鍵の保有が参加資格を示すとしても、個別の割当の正当性までは示さない。
時刻比較や決定的な優先規則は、プロトコルとしての勝者を選ぶだけである。ドラフトのBad Actor Listがローカルかつ上限付きで、補助的な扱いに留まるのも合理的だ。送信元は偽装でき、時刻の比較で負けただけでは悪意を証明できない。
RFC 1982はシリアル番号計算を、RFC 8085はUDP運用の注意を提供する。RFC 2365、RFC 5771、RFC 2730、RFC 2909は、スコープや以前の割当方式を記録している。RFC 10019とRFC 10028は、現在の構造と未解決領域を整理する。どれも、有効なパケットを資源の権原に変換する文書ではない。
小さいプロトコルの外側にある統治
Lu Hengの最小の初期仕様と地域ごとの将来判断、自発的採用という考え方は、GAAPの姿勢とよく合う。まず狭い仕組みを試し、運用から学び、必要のない厚い制度を先に築かない。それ自体は健全である。
問題は、プロトコルに書かれない権力が消えるわけではないことだ。鍵を配る者は参加者を選び、鍵を止める者は参加を終わらせる。誰のClaimが見えるかを決める者は、事実上、どの衝突が存在するかも決める。
実際に動くコードの優先という基準なら、確認すべきは表示上の「encrypted」ではない。受信者が実際に何を見て、鍵更新の失敗時に何をし、重複利用の損失を誰が負うかである。
BTWの既存記事「GAAP-23はアドレス範囲を修正したが、分断後の収束を未解決のまま残した」は、同じGroup Nameが分断後に別のフォールバックアドレスへ残る問題を扱った。第25版の暗号化はその課題を解決しない。ここでの新しい論点は、回線がつながっていても鍵が論理的な分断を作れることだ。
第25版はClaimの封筒を強くした。封筒を開けられることと、アドレスを使う権利は、最後まで分けて扱わなければならない。
情報源
- GAAPドラフト第25版
- IETF Datatracker
- IETF文書履歴
- GAAPドラフト第23版
- BTWによる既存のGAAP-23分析
- RFC 10019:マルチキャストアドレス割当アーキテクチャ
- RFC 10028:マルチキャストアドレス割当のギャップ分析
- RFC 8439:ChaCha20とPoly1305
- RFC 1982:シリアル番号算術
- RFC 8085:UDP利用指針
- RFC 2365:管理スコープIPマルチキャスト
- RFC 5771:IPv4マルチキャストアドレス割当
- RFC 2730:MADCAP
- RFC 2909:MADCAPスコープ入れ子状態オプション
- 最小初期仕様、地域ごとの将来判断、自発的採用
- 実行コードの優先
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

