導入
パス MTU ディスカバリ( PMTUd ) は、パケットの断片化を回避するために、コンピュータ ネットワークにおいて 2 つの IP ホスト間のパス上の MTU のサイズを決定する手法です。 ICMP については RFC 1191 によって定義され、ICMPv6 については RFC 1981 によって定義されます。
IP の断片化はルーターのパフォーマンスに影響を与え、セキュリティ上の問題も引き起こします。
機能している
特定のパスの MTU を検出するには、すべての発信パケットの IP ヘッダーの DF (Don’t Fragment)ビットを設定します。このようなパケットが通過するパスに沿って、通過するホストの 1 つの MTU がパケットのサイズより小さい場合、後者は破棄され、パケットを生成したホストの MTU を含む ICMPメッセージが送信されます。情報源に知らせるため。このメッセージは次のとおりです。
- ICMP のタイプ 3 / コード 4、「宛先に到達できません」 / 「フラグメンテーションが必要ですが、フラグメントを設定しないでください」
- ICMPv6 のタイプ 2 / コード 0、「パケットが大きすぎます」。
次に、送信元は、ICMP メッセージで受信した MTU に基づいて次のパケットのサイズを調整します。このプロセスは、送信元が宛先に到達するまで繰り返されます。
接続の確立後にパスの MTU が変更され、以前に決定されたものよりも小さいことが判明した場合、パスを通過するには大きすぎる最初のパケットによって新しい ICMP メッセージが送信され、PMTUD プロセスが再起動されます。同様に、接続中、送信元はパスを定期的に再調査して、より大きな MTU が許可されているかどうかを検出できます。
まれではありますが、このようなケースは、動的ルーティングプロトコルやネットワーク上での人的介入によるルート変更によって発生する可能性があります。
実装
PMTUd は IETF 標準の一部です。 ICMP を正しく実装するホストは PMTUd をサポートします。ただし、使用されるカウンタはオペレーティング システムによって異なる場合があります。
RFC 1191 および 1981 では、ICMP メッセージの受信後 5 分未満または 1分を超えて PMTUd が発生してはならないと規定しています。実装時には、これらの値を 2 倍した値 (つまり、10 分と 2 分) を使用することをお勧めします。
問題点
その有用性にもかかわらず、PMTUd には多くの問題があり、そのほとんどはセキュリティ上の制約に関連していますが、場合によってはインターネット上の送信パフォーマンスへの影響にも関連しています。
中間機器によるフィルタリング
ルーターやファイアウォールなどの多くのデバイスでは、デフォルトまたは管理者の決定に従って、ICMP トラフィックのすべてまたは一部をブロックできます。 ICMP に関連する既存の脆弱性が多数あるため、 Telnetやrshと同様に、ICMP全体を脆弱性として考えることが非常に一般的になっています。ただし、すべての ICMP メッセージを無差別にフィルタリングすると、ネットワーク インフラストラクチャに重大な誤動作が発生する可能性があります。
ICMP タイプ 3 / コード 4 メッセージがフィルタリングされると、PMTUd は失敗します。 PMTUd を実行しようとするホストは、過度に大きなパケットを送信し続けますが、そのパケットは通過せず、送信元にエラー メッセージが届きません。その後、パケットは「ブラックホール」に吸い込まれると言われています。
フィルタリングが部分的である場合でも、ping またはtraceroute は機能する可能性があるため、この問題を解決するのは困難です。同様に、TCP 接続も初期化でき、大きなセグメントが送信されない限り (対話型送信中など)、問題なく動作します。ブラック ホールの主な症状は、TCP 接続が長期間転送されないことです。
この問題は、特に RFC 1435 と RFC 2923 で長年にわたり詳細に議論されてきました。2000 年代の初めには、いくつかの重要な Web サイトがブラックホールとして機能してこの動作を修正することを奨励する取り組みも開始され、成功しました。
TCPとの対話
どのトランスポート層プロトコルも PMTUd の普及により恩恵を受けることができますが、TCP は最初の消費者であるため、その機能不全に最も悩まされているプロトコルでもあります。この事実を説明するために、 「パス MTU 検出に関する TCP の問題」というタイトルの RFC 2923 は、TCP と PMTUd の間の不幸な相互作用に完全に特化しています。
例として、MTU と MSS の関係における重要な問題の 1 つを示します。この最後のパラメータは、TCP 送信において、ソースが受信できる最大セグメント サイズを示します。多くのシステムは、PMTUd の結果に基づいて、接続の相手側にアドバタイズする MSS 値を決定します。ただし、インターネット上では非対称ルートが優勢であることがいくつかの調査で示されており、これは特定の送信の往路と復路の間で MTU が異なることを意味する可能性があります。 PMTUd を使用して発表された MSS を決定すると、次善のパフォーマンスにさらされることになります。この方法は RFC に違反しませんが、MSS の基礎としてシステム インターフェイスの MTU を使用することが望ましいです。
他の例とより完全な説明については、RFC 2923 を参照してください。
セキュリティリスク
RFC 1191 と RFC 1981 は、それぞれIPv4とIPv6の PMTUd について説明しており、セキュリティ上の考慮事項の観点から考えられるいくつかの攻撃に対処しています。最も深刻なのは、攻撃者が被害者との正当な接続の受信者を装う、少量のサービス拒否です。次に、攻撃者は ICMP メッセージを被害者に送信し、PMTUd プロセスをトリガーし、パケットのサイズをプロトコルの最小 MTU (IP ヘッダーとデータを含む IPv4 で 68 バイト、IPv6 で 1280 バイト) まで縮小します。 RFC では、パケット サイズを増やすことを目的とした PMTUdフェーズを再試行する前に 10 分間待機することを推奨しています。したがって、攻撃では、偽の ICMP メッセージを 10 分ごとに被害者に送信するだけで済みます。
確かにスループットは大幅に低下しますが、本当の影響は別のところにあります。同じスループットを維持するために、被害者は大量の小さなパケットを送信する必要があり、これにより、送信中のすべての機器、特に被害者に大量の中断が発生します。過負荷の影響により、特に攻撃が複数の接続で繰り返された場合、マシンは完全に応答を停止する可能性があります。
2005 年に、Fernando Gont は、上記のものを含む ICMP エラー メッセージを使用した TCP に対するいくつかの攻撃を導入しました。これを解決するために、彼は PMTUd を Initial Path-MTU と Path-MTU Update の 2 つの部分に分割することを提案しています。また、TCP に新しい状態変数、maxsizesent (送信された最大パケットのサイズ) と maxsizeacked (受信された最大パケットのサイズ) を追加することも提案しています。
初期パス MTU は、TCP が MTU を認識しない接続開始時のフェーズです。パス MTU 更新は、TCP がすでに MTU を認識しているため、受信した ICMP メッセージについてより注意する必要がある送信中のフェーズです。通常、 MTU の調整を伴う ICMP メッセージを受信すると、新しいチェックが導入されます。
- ICMP メッセージによって超過として通知された MTU が maxsizesent より大きい場合、ICMP メッセージは無視されます。
- ICMP メッセージによって超過として通知された MTU が maxsizeacked 以上である場合、ICMP メッセージが考慮され、MTU が調整されます。初期パス MTU にいます。
- ICMP メッセージによって超過として通知された MTU が maxsizeacked 未満の場合、ICMP メッセージは単に記録され、MTU 調整は遅れます。この調整遅延中に TCP セグメント確認応答が到着した場合、ICMP メッセージは無視されます。そうでない場合は、考慮されて MTU が調整されます。
調整までの時間は、特定の TCP セグメントが再送信タイムアウト (RTO) を超えた回数の関数です。いくつかのセグメントが結果なしで再送信されることは、実際、TCP が送信の問題を検出するために使用する古典的なメトリックです。