メインコンテンツまでスキップ

5. セキュリティの考慮事項

本セクションは, LDP が脆弱でありうる脅威を特定し, それらの脅威を緩和しうる手段について論じる.

5.1. スプーフィング​

スプーフィング攻撃の標的となりうる LDP 通信には 2 種類ある.

  1. UDP で運ばれる Discovery 交換

    LSR は, Hello メッセージを定期的に送信することによって, LDP セッションを確立および維持する意思を示す. Hello の受信は, 「Hello 隣接」がまだ存在しない場合に新たにそれを作成し, または既存のものをリフレッシュする働きをする. 既存の隣接に対する Hello パケットをスプーフィングすると, その隣接がタイムアウトし, その結果として関連するセッションが終了しうる. これは, スプーフィングされた Hello が小さな Hold Time を指定した場合に発生しうる. すなわち, 受信側はその間隔内に Hello を期待するようになる一方, 真の隣接は以前に合意したより低い頻度で Hello を送信し続ける.

    リンクレベルで直接接続された LSR は, リンク上で Basic Hello メッセージを交換する. スプーフィングされた Basic Hello の脅威は, 次のことによって低減できる:

    o 信頼できる LSR が直接接続されているインタフェースでのみ Basic Hello を受け入れる.

    o All Routers on this Subnet マルチキャストグループ宛てでない Basic Hello を無視する.

    リンクレベルで直接接続されていない LSR は, LDP セッションを確立する意思を示すために Extended Hello メッセージを使用してよい. LSR は, Extended Hello をフィルタリングし, アクセスリストによって許可された送信元から発信されたもののみを受け入れることによって, スプーフィングされた Extended Hello の脅威を低減できる.

  2. TCP で運ばれるセッション通信

    LDP は, セッションメッセージの真正性と完全性を提供するために, TCP MD5 Signature Option の使用を規定する.

    [RFC2385] は, MD5 認証は今やこの用途には弱すぎると一部の人々によって考えられていると主張している. またそれは, より強いハッシュアルゴリズム (例として SHA-1 を挙げている) を用いた類似の TCP オプションを配備できることも指摘している. 我々の知る限り, そのような TCP オプションは定義も配備もされていない. しかし, LDP は利用可能な任意の TCP メッセージダイジェスト技術を使用でき, MD5 より強いものが規定および実装された場合, それを使用するよう LDP をアップグレードすることは比較的容易であろう.

5.2. プライバシー​

LDP は, ラベル配布のプライバシーを保護するためのメカニズムを提供しない.

ラベル配布プロトコルのセキュリティ要件は, ルーティング情報を配布するプロトコルのそれと本質的に同一である. 自身のメッセージの真正性と完全性を保証するメカニズムを提供することにより, LDP は, ルーティングプロトコル自体が提供できるものと少なくとも同等 (ただしそれ以上ではない) のレベルのセキュリティを提供する. ルーティングプロトコルにプライバシーを要求すべきかどうかというより一般的な問題は, 本文書の範囲を超える.

ラベル配布は, ラベルスプーフィングの脅威に対処するためにプライバシーを要求すると論じることもできよう. しかし, データパケットはラベルを平文で運ぶため, そのプライバシーはラベルスプーフィング攻撃を防がないであろう. さらに, ラベルスプーフィング攻撃は, ラベルにバインドされた FEC を知らなくても行うことができる.

ラベルスプーフィング攻撃を回避するには, ラベル付きデータパケットが信頼できる LSR によってラベル付けされ, またパケットに付与されるラベルがラベル付けを行う LSR によって適切に学習されていることを保証する必要がある.

5.3. サービス妨害​

LDP は, サービス妨害 (Denial of Service, DoS) 攻撃に対して 2 つの潜在的な標的を提供する:

  1. LDP Discovery 用の周知の UDP ポート

    LSR 管理者は, Basic Hello を介した DoS 攻撃の脅威に, その LSR が, そのような攻撃を開始しないと信頼できるピアにのみ直接接続されるようにすることによって対処できる. 管理者のドメイン内部のピアへのインタフェースは, 内部ピアが管理者の制御下にあるため, 脅威とはならないはずである. ドメイン外部のピアへのインタフェースは, 外部ピアが制御下にないため, 潜在的な脅威となる. 管理者は, その LSR を, Basic Hello 攻撃を開始しないと信頼できる外部ピアにのみ接続することによって, その脅威を低減できる.

    Extended Hello を介した DoS 攻撃は, より深刻な脅威となりうる. この脅威には, Extended Discovery が許可されるアドレスを定義するアクセスリストを用いて Extended Hello をフィルタリングすることによって対処できる. しかし, フィルタリングを行うには LSR の資源を要する.

    信頼できる MPLS クラウドを識別できる環境では, クラウドのエッジにある LSR を, Extended Hello を介した DoS 攻撃から内部 LSR を保護するために使用できる. すなわち, 信頼できる MPLS クラウドの外部から発信された Extended Hello をフィルタリングし, アクセスリストによって許可されたアドレスから発信されたもののみを受け入れる. このフィルタリングはクラウド内部の LSR を保護するが, エッジで資源を消費する.

  2. LDP セッション確立用の周知の TCP ポート

    他の TCP を使用する制御プレーンプロトコルと同様, LDP は SYN 攻撃のような DoS 攻撃の標的となりうる. LDP は, TCP を使用する他の制御プレーンプロトコルと比べて, そのような攻撃に対してより脆弱でもより堅牢でもない.

    そのような攻撃の脅威は, 次のことによってある程度緩和できる:

    o LSR は, LDP セッション確立のために無差別な (promiscuous) TCP listen を避けることが望ましい (SHOULD). それは, 発見されたピアに固有の listen のみを使用することが望ましい (SHOULD). これにより, 攻撃パケットは既存または進行中の接続に一致する可能性が低いため, その処理の早い段階で破棄できる.

    o MD5 オプションの使用は, MD5 セグメントチェックサムが有効でない限り SYN が受け入れられないようにするため, ある程度役立つ. しかし, 受信側は, それ以外は受け入れ可能な SYN セグメントを破棄すると決定する前に, チェックサムを計算しなければならない.

    o MPLS クラウドの境界に, 上記の Extended Hello について示唆したものと同様の方法でアクセスリストの仕組みを適用することにより, クラウド外部から発信される攻撃から内部を保護できる.