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

6. ICMP処理 (ICMP Processing)

このセクションでは、ICMPトラフィックのIPsec処理について説明します。ICMPトラフィックには2つのカテゴリがあります:エラーメッセージ(例:type = 宛先到達不可能)と非エラーメッセージ(例:type = エコー)。このセクションは、エラーメッセージにのみ適用されます。非エラーICMPメッセージ(IPsec実装自体にアドレス指定されていないもの)の処理は、SPDエントリを使用して明示的に説明しなければなりません(MUST)。

このセクションの議論は、ICMPv4だけでなくICMPv6にも適用されます。また、管理者がICMPエラーメッセージ(選択されたもの、すべて、またはなし)を問題診断の助けとしてログに記録できるようにするメカニズムを提供すべきです(SHOULD)。

6.1. IPsec実装に向けられたICMPエラーメッセージの処理 (Processing ICMP Error Messages Directed to an IPsec Implementation)

6.1.1. 境界の保護されていない側で受信されたICMPエラーメッセージ (ICMP Error Messages Received on the Unprotected Side of the Boundary)

セクション5.2の図3は、IPsec境界の保護されていない側に、IPsecデバイスにアドレス指定され、AHまたはESPを介して保護されていないICMPメッセージ(エラーまたはその他)を処理するための別個のICMP処理モジュールを示しています。この種のICMPメッセージは認証されておらず、その処理はサービス拒否またはサービス低下をもたらす可能性があります。これは、一般的に、そのようなメッセージを無視することが望ましいことを示唆しています。しかし、多くのICMPメッセージは、ホストまたはセキュリティゲートウェイによって、認証されていないソース(例えば、パブリックインターネット内のルーター)から受信されます。これらのICMPメッセージを無視すると、例えばPMTUメッセージとリダイレクトメッセージの処理の失敗により、サービスが低下する可能性があります。したがって、認証されていないICMPメッセージを受け入れて処理する動機もあります。

このスペクトラムの両端に対応するため、準拠したIPsec実装は、ローカル管理者がIPsec実装を構成して、認証されていないICMPトラフィックを受け入れるか拒否するかを許可しなければなりません(MUST)。この制御は、ICMPタイプの粒度でなければならず(MUST)、ICMPタイプとコードの粒度であってもかまいません(MAY)。さらに、実装は、そのようなトラフィックを処理するためのメカニズムとパラメータを組み込むべきです(SHOULD)。

ICMP PMTUメッセージが上記のチェックに合格し、システムがそれを受け入れるように構成されている場合、2つの可能性があります。実装が境界の暗号文側でフラグメンテーションを適用する場合、受け入れられたPMTU情報は転送モジュール(IPsec実装の外部)に渡され、アウトバウンドパケットのフラグメンテーションを管理するために使用されます。実装が平文側のフラグメンテーションを実行するように構成されている場合、PMTU情報は平文側に渡され、セクション8.2で説明されているように処理されます。

6.1.2. 境界の保護された側で受信されたICMPエラーメッセージ (ICMP Error Messages Received on the Protected Side of the Boundary)

これらのICMPメッセージは認証されていませんが、IPsec境界の保護された側のソースから来ています。したがって、これらのメッセージは一般的に、境界の保護されていない側のソースから到着する対応するメッセージよりも「信頼できる」と見なされます。ここでの主なセキュリティ上の懸念は、侵害されたホストまたはルーターが、セキュリティゲートウェイの「背後」にある他のデバイスのサービスを低下させる可能性のある誤ったICMPエラーメッセージを発行する可能性があること、またはそれが機密性の侵害をもたらす可能性さえあることです。したがって、実装者は、境界の保護された側で受信され、IPsec実装に向けられたICMPエラーメッセージの処理を制約できるようにするための制御をローカル管理者に提供しなければなりません(MUST)。

6.2. 保護された、トランジットICMPエラーメッセージの処理 (Processing Protected, Transit ICMP Error Messages)

ICMPエラーメッセージがSAを介してIPsec実装の「背後」にあるデバイスに送信される場合、ICMPメッセージのペイロードとヘッダーの両方がアクセス制御の観点からチェックを必要とします。これらのメッセージの1つがセキュリティゲートウェイの背後のホストに転送される場合、受信ホストIP実装は、ペイロード、つまりエラー応答をトリガーしたとされるパケットのヘッダーに基づいて決定を行います。したがって、IPsec実装は、このペイロードヘッダー情報が到着したSAと一致しているかどうかをチェックするように構成可能でなければなりません(MUST)。

両方のポリシーに対応するために、次の規則が採用されています。管理者がペイロードの検査なしにICMPエラーメッセージをSAによって運搬されることを許可したい場合は、そのようなトラフィックの運搬を明示的に許可するSPDエントリを構成します。管理者がIPsecにICMPエラーメッセージのペイロードの一貫性をチェックさせたい場合は、ICMPパケットヘッダーに基づいてそのようなトラフィックの運搬に対応するSPDエントリを作成しません。

IPsec送信者と受信者は、SAを介して送受信されるICMPエラーメッセージに対して次の処理をサポートしなければなりません(MUST):

  • アウトバウンドICMPエラーメッセージに対応するSAが存在する場合、メッセージはSAにマップされ、受信時にはIPおよびICMPヘッダーのみがチェックされます。

  • ICMPエラーメッセージに関連付けられたトラフィックセレクタと一致するSAが存在しない場合、そのようなSAを作成できるかどうかを判断するためにSPDが検索されます。

  • 問題のアウトバウンドICMPメッセージを運ぶSAが存在せず、このアウトバウンドICMPエラーメッセージの運搬を許可するSPDエントリがない場合、IPsec実装は、ICMPエラーメッセージをトリガーしたパケットに関連付けられたリターントラフィックを運ぶSAにメッセージをマップしなければなりません(MUST)。

  • IPsec実装がSA上でインバウンドICMPエラーメッセージを受信し、メッセージのIPおよびICMPヘッダーがSAのトラフィックセレクタと一致しない場合、受信者は受信したメッセージを特別な方法で処理しなければなりません(MUST)。


関連セクション: