RFC 4379 - 6. Security Considerations

6. セキュリティ考慮事項 (Security Considerations)

全体として、LSP ping のセキュリティ要件は ICMP ping と類似している。

ここで定義する機構を悪用して LSR を攻撃する方法は少なくとも 3 つある。1 つは、MPLS echo request/reply を LSR に送信してその処理負荷を増大させるサービス拒否攻撃。2 つめは、MPLS echo request と reply を偽造、ハイジャック、再生、またはその他改ざんし、MPLS データプレーンの生存状態を混乱させること。3 つめは、権限のない送信元が LSP ping を利用してネットワーク情報を取得すること。

潜在的なサービス拒否攻撃を避けるため、コントロールプレーンへ送られる LSP ping トラフィックを調整する実装が RECOMMENDED である。ここで定義する well-known UDP ポートにはレートリミッタを適用すべき (SHOULD) である。

MPLS echo reply の単純な再生およびなりすまし攻撃は効果が低い可能性が高い。これらの応答は、未完了の MPLS echo request の Sender's Handle と Sequence Number に一致しなければならない。一致しない再生はシーケンスが進んでいるため破棄され、したがってなりすましの機会の窓は小さい。しかしより強い防御のため、実装は MAY で TimeStamp Sent フィールドの厳密な一致を検証してもよい。

権限のない送信元が MPLS echo request を利用してネットワーク情報を取得するのを防ぐため、実装は RECOMMENDED で、メッセージ受信前に MPLS echo request メッセージのソースアドレスをアクセス制御リストで照査する手段を提供すべきである。

echo request または reply をハイジャック (配送しない) するのをどう防ぐかは不明である；しかしこれらのメッセージが実際にハイジャックされた場合、LSP ping はデータプレーンが期待通りに動作していないと報告するだろう。

MPLS echo request と reply に載るデータの保護は (現在は) 重要ではないように見えるが、一部の関係者は MPLS データプレーン状態の知識を機密とみなすかもしれない。しかし実装は SHOULD で、echo reply の送信先アドレスをフィルタリングする手段を提供すべきである。

本ドキュメントは 127/8 アドレスの特殊な使用をするが、これらは UDP ポート 3503 との組み合わせでのみ使用される。さらに、これらのパケットはルータのみが処理する。他のすべてのホストは、宛先アドレスが 127/8 範囲内のすべてのパケットを RFC 1122 に従って処理しなければならない (MUST)。ルータが受信した宛先アドレスが 127/8 範囲だが宛先 UDP ポートが 3503 でないパケットは、RFC 1812 に従って処理しなければならない (MUST)。特に、既定の動作は 127/8 宛のパケットを "martians" (偽アドレス) とみなすことである。