要約

  • 暗号学的生成アドレス（CGA）はIPv6のインターフェース識別子を公開鍵に結び付ける。署名が示すのは対応する秘密鍵を扱えることまでで、人の身元やルーターの権限ではない。
  • ルーターを認可するには、ホスト側にあらかじめ設定された信頼アンカーが要る。SENDはこの依存をなくさず、見える形にした。

IPv6のホストがリンクにつながった直後、まず必要なのは近隣の発見だ。リンク層アドレスを解決し、ルーターを見つけ、到達可能性を保つ。攻撃者がここで偽の情報を差し込めば、上位の通信が始まる前に判断が狂うことがある。RFC 4861はこの仕組みを定義した。IPsecによる保護も想定されていたが、利用手順は十分に具体化されておらず、多数の相手に手作業でSecurity Associationを設定するのは現実的でない場合があるとRFC 3971は説明する。

SENDの設計は、すべてをひとつの証明に押し込まない。ノードがアドレスに対応する鍵を扱えるかどうかには、暗号学的生成アドレス（CGA）を使える。RFC 3972は公開鍵と補助パラメーターからインターフェース識別子を導く。受信側はハッシュを再計算して対応を確かめ、公開鍵でメッセージ署名を検証する。このアドレスと鍵の結び付きに、認証局は必須ではない。

ただし、その保証は狭い。RFC 3972は、攻撃者が自分の鍵を使い、任意のサブネットプレフィックスの下で新しいCGAを作れると明記する。既存の他者のCGAを使って、その人のように署名することはできない。CGAは実在の個人や組織を識別せず、プレフィックスの割当てを証明せず、ルーターとして広告する許可も与えない。

メッセージの真正性と要求への応答関係にも別の仕組みがある。RFC 3971のNonceオプションは、広告がそれを促した solicitation と結び付くことを助け、タイムスタンプは署名済みの未要求メッセージを扱う際の再送対策に使われる。これらは古いメッセージを別の形で検証するもので、証明書の信頼アンカーを置き換えない。署名、鮮度、ルーター認可はそれぞれ別の仕事を持つ。

ルーターの認可には別の証明経路がある。ホストはルーター証明書を検証し、すでに設定してある信頼アンカーまでたどらなければならない。SENDのAuthorization Delegation Discoveryは証明書パスの取得を助けるが、未知のルートを信頼できるものにはしない。「ゼロ設定」はCGAによる鍵の結び付けについての表現であって、ルーター認可を含む全体の性質ではない。

後続文書もこの境界を補った。RFC 6494はリソース証明書に基づくSEND証明書プロファイルを定め、RFC 6495はSubject Key Identifier用の名前型を定義した。RFC 6980は、監視やフィルタリングをすり抜ける可能性のあるフラグメントへの対処として、NDとSENDの一部メッセージでIPv6断片化を禁じた。これは仕様の更新履歴であり、普及率や実ネットワークでの安全性を示す資料ではない。

RFC 3971を読むときの要点は、信頼を消したという話にしないことだ。アドレスに署名できる証拠と、ルーターを認可する根拠は別々に設計された。