12. Security Considerations (セキュリティの考慮事項)
12. Security Considerations (セキュリティの考慮事項)
制御プレーンプロセスを使用して EID-to-RLOC マッピングを取得する場合, ほとんどのセキュリティメカニズムはマッピングデータベースサービスの一部になると考えられています。この仕様で説明されているデータプレーントリガーマッピングの場合, ETR スプーフィングに対する保護は, ルーティング返送可能性 (セクション 3 を参照) メカニズムを使用し, LISP カプセル化ヘッダの 24 ビット 'Nonce' フィールドと LISP 制御メッセージの 64 ビット 'Nonce' フィールドを使用して証明することによって提供されます。
nonce と, ITR が要求した Map-Reply のみを受け入れることにより, 現在のインターネットルーティングシステムで経験されるセキュリティと多くの点で類似した基本的なセキュリティレベルが提供されます。パス外の攻撃者がこれらの LISP メカニズムに対して攻撃を仕掛けることは困難です。nonce 値を持っていないためです。正しい nonce 値を偶然に見つけるために大量のパケットを送信することは可能ですが, これ自体がサービス拒否 (DoS) 攻撃です。パス内の攻撃者はより深刻な攻撃を実行できますが, パス内の攻撃者は現在のインターネットでも, 盗聴, ブロッキング, またはトラフィックのリダイレクトを含む深刻な攻撃を仕掛けることができます。このトピックに関する詳細な議論については, セクション 6.1.5.1 を参照してください。
LISP は PKI やより重量級の認証システムに依存しません。これらのシステムは, LISP の主要な設計目標の 1 つであるスケーラビリティに挑戦します。
DoS 攻撃の防止は, 実装が制御プレーンへの Map-Request と Map-Reply, およびデータトリガー Map-Reply の数をレート制限することに依存します。
正しく実装されていないまたは悪意のある ITR は, ETR がその Map-Reply で提供する Priority と Weight を無視することを選択する可能性があります。このトラフィック誘導は, この ITR サイトから送信されるトラフィックに限定され, サイトが ETR の入口リンクの 1 つで帯域幅 DoS 攻撃を開始するよりも悪くありません。ITR のサイトは通常, Weight を尊重しないことから何の利益も得られず, それらを尊重することでより良いサービスを得る可能性があります。
ITR/PITR での map-cache 枯渇の試みに対処するため, 実装は保存されるエントリ数に最大上限を設定し, 特別なまたは頻繁にアクセスされるサイトのリストを予約することを検討すべきです。これは, ITR と PITR を管理するネットワーク管理者によって設定される構成ポリシーによって制御されるべきです。複数の Map-Cache エントリにわたって重複する EID-Prefix が存在する場合, セットの整合性を完全に維持しなければなりません。したがって, 最大上限に達したためにより具体的なエントリを追加できない場合, それほど具体的でないエントリも map-cache に保存すべきではありません。
ITR/PITR が EID-to-RLOC マッピングのキャッシュを維持することを考えると, キャッシュサイズと維持は実装中に覚えておくべき問題です。キャッシュチャーンを検出するためのインストルメンテーションをインストールすることは良い考えです。実装実験を使用して, どのキャッシュ管理ポリシーが最も効果的かを判断します。一般的に, キャッシュチャーン攻撃を防御することは困難です。ITR/PITR のキャッシュが小さすぎると, サポートするサイトまたはエリアに悪影響を与えるだけでなく, マッピングシステムでの Map-Request 負荷が増加する可能性があることに注意すべきです。
セクション 6.1.3 で説明されている「Piggybacked (ピギーバック)」マッピングデータは, このようなマッピングをどのように処理するかを指定し, ETR が「信頼された」環境で動作している場合に検証前に一時的にこのようなマッピングを受け入れる可能性を含みます。この場合, (たとえ短時間であっても) 虚偽のマッピングが map-cache に挿入される可能性があるという潜在的な脅威が存在します。セクション 6.1.3 で述べたように, ETR はこのようなモードで動作するように明示的に構成されなければならず, 同じ信頼された環境で動作していると見なされる特定の ITR のみを考慮する可能性があります。
ETR が応答している EID-Prefix を生成するという事実にはセキュリティリスクがあります。ETR は実際に責任を負うよりも短いプレフィックスを主張できます。この問題を改善または解決するさまざまなメカニズムが将来研究されます [LISP-SEC]。
LISP カプセル化パケットの内部ヘッダアドレスのスプーフィングは, 任意のトンネリングメカニズムと同様に可能です。ITR は, カプセル化前にパケットの送信元アドレスがサイトの EID-Prefix 範囲に属する EID であることを検証しなければなりません。ETR は, 内部ヘッダの宛先がその EID-Prefix 範囲の 1 つと一致するデータグラムのみをカプセル化解除して転送しなければなりません。受信とカプセル化解除時に, データグラムの宛先 EID が ETR が構成した EID-Prefix の 1 つと一致しない場合, ETR はそのデータグラムをドロップしなければなりません。LISP カプセル化パケットが ETR に到着した場合, 内部ヘッダの送信元 EID アドレスと外部ヘッダの送信元 RLOC アドレスをマッピングデータベースに存在するマッピングと比較すべきです。その後, スプーフィング攻撃が発生した場合, 外部ヘッダの送信元 RLOC アドレスを使用して既存の運用ツールで攻撃を送信元サイトまで追跡できます。
この実験仕様は自動鍵管理 (AKM) に対応していません。BCP 107 [RFC4107] はこの分野でガイダンスを提供します。さらに, 本文書の執筆時点では, ルーティングシステムのセキュリティを改善するための大量の作業が進行中です [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]。LISP に関する将来の作業は, BCP 107 で議論されている問題と他の未解決のセキュリティ考慮事項に対処すべきであり, これには本仕様への変更が必要になる可能性があります。