13. Security Considerations (セキュリティに関する考慮事項)

この文書はセキュリティプロトコルを説明しているため, セキュリティ上の関心の多くの側面は関連するセクションで説明されています。このセクションでは, 他のセクションでは明らかでない可能性のある問題を指摘します。

Cache Validation (キャッシュ検証): 第 11 節で説明されているキャッシュのコレクションが一貫したビューを保証するためには, 内部検証プロセスで使用する一貫したトラストアンカーを与えられる必要があります。一貫したトラストアンカーの配布は帯域外であると想定されています。

Cache Peer Identification (キャッシュピア識別): ルーターは, IP アドレスまたは完全修飾ドメイン名のいずれかで識別するキャッシュへのトランスポート接続を開始します。DNS またはアドレススプーフィング攻撃により正しいキャッシュが到達不能になる可能性があることに注意してください。認可キーが一致しないため, セッションは確立されません。

Transport Security (トランスポートセキュリティ): RPKI は, サーバーやトランスポートではなく, オブジェクトの信頼に依存しています。つまり, IANA ルートトラストアンカーは帯域外の手段を通じてすべてのキャッシュに配布され, 各キャッシュがツリー全体の証明書と ROA を検証するために使用できます。キャッシュ間の関係は, このオブジェクトセキュリティモデルに基づいています; したがって, キャッシュ間のトランスポートは軽く保護できます。

ただし, このプロトコル文書は, ルーターが検証暗号化を実行できないと想定しています。したがって, キャッシュからルーターへの最後のリンクは, サーバー認証とトランスポートレベルのセキュリティによって保護されます。これは危険です。サーバー認証とトランスポートは, オブジェクトセキュリティとは非常に異なる脅威モデルを持っているためです。

したがって, ルーターとキャッシュ間の信頼関係とトランスポートの強度は重要です。これにルーティングを賭けているのです。

キャッシュは同じ LAN 上にある必要があるとは言えませんが, 企業が上流 ISP にキャッシュタスクをオフロードしたいという問題だけでも, 局所性, 信頼, および制御はここで非常に重要な問題です。キャッシュは, 制御され保護された (DDoS, MITM に対して) トランスポートの意味で, ルーターにできるだけ近くあるべきです。また, ルーターのキャッシュへのアクセスをブートストラップするために必要な検証済みルーティングデータが最小限になるように, トポロジー的に近くあるべきです。

キャッシュサーバーの ID は, データが交換される前に, ルータークライアントによって検証および認証されるべきであり, その逆も同様です。

必要な認証と整合性を提供できないトランスポート (第 9 節を参照) は, スプーフィング/破損攻撃に対する保護を提供するためにネットワーク設計と運用制御に依存する必要があります。第 9 節で指摘されているように, TCP-AO は長期的な計画です。整合性と真正性を提供するプロトコルを使用すべきであり, それができない場合, つまり TCP がトランスポートとして使用される場合, ルーターとキャッシュは同じ信頼された制御されたネットワーク上にある必要があります。