[要約] RFC 6181は、TCPの拡張機能であるMultipath Operation with Multiple Addressesの脅威分析を提供しています。このRFCの目的は、TCPのマルチパスオペレーションに関連するセキュリティ上の脅威を特定し、対策を提案することです。
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6181 UC3M
Category: Informational March 2011
ISSN: 2070-1721
Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
複数のアドレスを備えたマルチパス操作のためのTCP拡張の脅威分析
Abstract
概要
Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP.
MultiPath TCP（略してMPTCP）は、特定のTCP接続のエンドポイントが複数のパスを使用してデータを交換できるように、TCPに提案された拡張機能を説明します。このような拡張により、異なるソース照明アドレスペアを使用してセグメントを交換できるようになり、かなりの数のシナリオで複数のパスを使用する機能が得られます。これらの拡張機能を通じて、ある程度のマルチホームとモビリティサポートを実現できます。ただし、エンドポイントごとの複数のIPアドレスのサポートは、結果のMPTCPのセキュリティに影響を与える可能性があります。このメモには、MPTCPの脅威分析が含まれています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6181.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6181で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Basic MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Flooding Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
6. Hijacking Attacks . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Hijacking Attacks to the Basic MPTCP . . . . . . . . . . . 10
6.2. Time-Shifted Hijacking Attacks . . . . . . . . . . . . . . 13
6.3. NAT Considerations . . . . . . . . . . . . . . . . . . . . 14
7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Multipath TCP (MPTCP for short) describes the extensions proposed for TCP [RFC0793] so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. There are many other ways to provide multiple paths for a TCP connection other than the usage of multiple addresses. The threat analysis performed in this document is limited to the specific case of using multiple addresses per endpoint.
MultiPath TCP（略してMPTCP）は、特定のTCP接続のエンドポイントが複数のパスを使用してデータを交換できるように、TCP [RFC0793]に提案された拡張機能を説明します。このような拡張により、異なるソース照明アドレスペアを使用してセグメントを交換できるようになり、かなりの数のシナリオで複数のパスを使用する機能が得られます。これらの拡張機能を通じて、ある程度のマルチホームとモビリティサポートを実現できます。ただし、エンドポイントごとの複数のIPアドレスのサポートは、結果のMPTCPのセキュリティに影響を与える可能性があります。このメモには、MPTCPの脅威分析が含まれています。複数のアドレスの使用以外に、TCP接続に複数のパスを提供する他の多くの方法があります。このドキュメントで実行される脅威分析は、エンドポイントごとに複数のアドレスを使用する特定のケースに限定されています。
There are multiple ways to achieve Multipath TCP. Essentially, what is needed is for different segments of the communication to be forwarded through different paths by enabling the sender to specify some form of path selector. There are multiple options for such a path selector, including the usage of different next hops, using tunnels to different egress points, and so on. The scope of the analysis included in this note is limited to a particular approach, namely MPTCP, that relies on the usage of multiple IP address per endpoint and that uses different source-destination address pairs as a means to express different paths. So, in the rest of this note, the MPTCP expression will refer to this multi-addressed flavor of Multipath TCP [MPTCP-MULTIADDRESSED].
MultiPath TCPを達成するには、複数の方法があります。基本的に、必要なのは、送信者が何らかの形のパスセレクターを指定できるようにすることにより、さまざまなパスを通じて通信のさまざまなセグメントを転送することです。このようなパスセレクターには、さまざまな次のホップの使用、トンネルを異なる出力ポイントに使用するなど、複数のオプションがあります。このメモに含まれる分析の範囲は、特定のアプローチ、すなわちMPTCPに限定されています。これは、エンドポイントごとに複数のIPアドレスの使用に依存し、異なるパスを表現する手段として異なるソースデステーションアドレスペアを使用します。したがって、このメモの残りの部分では、MPTCP式は、マルチパスTCP [MPTCP-MultiAddressed]のこの多重化されたフレーバーを指します。
This goal of this note is to perform a threat analysis for MPTCP. Introducing the support of multiple addresses per endpoint in a single TCP connection may result in additional vulnerabilities compared to single-path TCP. The scope of this note is to identify and characterize these new vulnerabilities. So, the scope of the analysis is limited to the additional vulnerabilities resulting from the multi-address support compared to the current TCP (where each endpoint only has one address available for use per connection). A full analysis of the complete set of threats is explicitly out of the scope. The goal of this analysis is to help the MPTCP designers create an MPTCP specification that is as secure as the current TCP. It is a non-goal of this analysis to help in the design of MPTCP that is more secure than regular TCP.
このメモのこの目標は、MPTCPの脅威分析を実行することです。単一のTCP接続でエンドポイントごとの複数のアドレスのサポートを導入すると、単一パスTCPと比較して追加の脆弱性が発生する場合があります。このメモの範囲は、これらの新しい脆弱性を特定し、特徴付けることです。したがって、分析の範囲は、現在のTCP（各エンドポイントが接続ごとに使用できるアドレスが1つしかない）と比較して、マルチアドレスサポートに起因する追加の脆弱性に限定されます。脅威の完全なセットの完全な分析は、明示的に範囲外です。この分析の目標は、MPTCP設計者が現在のTCPと同じくらい安全なMPTCP仕様を作成できるようにすることです。これは、通常のTCPよりも安全なMPTCPの設計に役立つこの分析の非ゴールです。
The focus of the analysis is on attackers that are not along the path, at least not during the whole duration of the connection. In the current single-path TCP, an on-path attacker can launch a significant number of attacks, including eavesdropping, connection hijacking Man-in-the-Middle (MiTM) attacks, and so on. However, it is not possible for the off-path attackers to launch such attacks. There is a middle ground in case the attacker is located along the path for a short period of time to launch the attack and then moves away, but the attack effects still apply. These are the so-called time-shifted attacks. Since these are not possible in today's TCP, they are also consider in the analysis. So, summarizing, both attacks launched by off-path attackers and time-shifted attacks are considered to be within scope. Attacks launched by on-path attackers are out of scope, since they also apply to current single-path TCP.
分析の焦点は、少なくとも接続の全期間中ではなく、パスに沿っていない攻撃者にあります。現在のシングルパスTCPでは、パス上の攻撃者は、盗聴、中間のマン（MITM）攻撃などの接続ハイジャックなど、かなりの数の攻撃を開始できます。ただし、オフパスの攻撃者がそのような攻撃を開始することは不可能です。攻撃者が攻撃を開始するために短期間パスに沿って配置されてから離れて移動する場合に備えて中間地面がありますが、攻撃効果はまだ適用されます。これらは、いわゆるタイムシフト攻撃です。これらは今日のTCPでは不可能であるため、分析でも考慮されます。したがって、要約すると、オフパス攻撃者によって開始された両方の攻撃とタイムシフトされた攻撃は、範囲内であると見なされます。現在のシングルパスTCPにも適用されるため、パス上の攻撃者によって開始された攻撃は範囲外です。
However, that some current on-path attacks may become more difficult with Multipath TCP, since an attacker (on a single path) will not have visibility of the complete data stream.
ただし、攻撃者（単一のパス上の）が完全なデータストリームの可視性を持たないため、MultiPath TCPでは現在のパス上の攻撃がより困難になる可能性があります。
There is a significant amount of previous work in terms of analysis of protocols that support address agility. The most relevant ones are presented in this section.
アドレスの俊敏性をサポートするプロトコルの分析に関して、かなりの量の以前の研究があります。最も関連性の高いものは、このセクションで示されています。
Most of the problems related to address agility have been deeply analyzed and understood in the context of Route Optimization support in Mobile IPv6 (MIPv6 RO) [RFC3775]. [RFC4225] includes the rationale for the design of the security of MIPv6 RO. All the attacks described in the aforementioned analysis apply here and are an excellent basis for our own analysis. The main differences are as follows:
アドレスの俊敏性に関連する問題のほとんどは、モバイルIPv6（MIPV6 RO）[RFC3775]のルート最適化サポートのコンテキストで深く分析および理解されています。[RFC4225]には、MIPV6 ROのセキュリティの設計の理論的根拠が含まれています。前述の分析に記載されているすべての攻撃は、ここに適用され、私たち自身の分析のための優れた根拠です。主な違いは次のとおりです。
o In MIPv6 RO, the address binding affects all the communications involving an address, while in the MPTCP case, a single connection is at stake. If a binding between two addresses is created at the IP layer, this binding can and will affect all the connections that involve those addresses. However, in MPTCP, if an additional address is added to an ongoing TCP connection, the additional address will/can only affect the connection at hand and not other connections, even if the same address is being used for those other connections. The result is that, in MPTCP, there is much less at stake and the resulting vulnerabilities are less. On the other hand, it is very important to keep the assumption valid that the address bindings for a given connection do not affect other connections. If reusing of binding or security information is to be considered, this assumption could be no longer valid and the full impact of the vulnerabilities must be assessed.
o MIPV6 ROでは、アドレスバインディングはアドレスを含むすべての通信に影響しますが、MPTCPの場合、単一の接続が危機にatしています。2つのアドレス間のバインディングがIPレイヤーで作成された場合、このバインディングは、それらのアドレスを含むすべての接続に影響を与える可能性があります。ただし、MPTCPでは、進行中のTCP接続に追加のアドレスが追加された場合、追加のアドレスは、他の接続に同じアドレスが使用されていても、他の接続ではなく、手元の接続にのみ影響します。その結果、MPTCPでは、危険にさらされており、結果として生じる脆弱性は少なくなります。一方、特定の接続のアドレスバインディングが他の接続に影響しないことを確認することは非常に重要です。拘束力のある情報またはセキュリティ情報の再利用を考慮する場合、この仮定はもはや有効ではなく、脆弱性の完全な影響を評価する必要があります。
o In MIPv6, there is a trusted third party, called the Home Agent that can help with some security problems, as expanded in the next bullet.
o MIPV6には、次の弾丸で拡張されるように、いくつかのセキュリティの問題に役立つホームエージェントと呼ばれる信頼できる第三者がいます。
o In MIPv6 RO, there is the assumption that the original address (Home Address) through which the connection has been established is always available, and in case it is not, the communication will be lost. This is achieved by leveraging in the on the trusted party (the Home Agent) to relay the packets to the current location of the Mobile Node. In MPTCP, it is an explicit goal to provide communication resilience when one of the address pairs is no longer usable, so it is not possible to leverage on the original address pair to be always working.
o MIPV6 ROでは、接続が確立された元のアドレス（ホームアドレス）が常に利用可能であり、そうでない場合は通信が失われるという仮定があります。これは、オントラストパーティー（ホームエージェント）を活用して、パケットをモバイルノードの現在の場所に中継することによって達成されます。MPTCPでは、アドレスペアの1つが使用できなくなった場合にコミュニケーションの回復力を提供することは明確な目標であるため、元のアドレスペアを活用して常に機能することはできません。
o MIPv6 RO is, of course, designed for IPv6, and it is an explicit goal of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO security solutions rely on the usage of some characteristics of IPv6 (such as the usage of Cryptographically Generated Addresses (CGA) [RFC3972]), which will not be usable in the context of MPTCP.
o もちろん、MIPV6 ROはIPv6向けに設計されており、IPv6とIPv4の両方をサポートするMPTCPの明示的な目標です。一部のMIPV6 ROセキュリティソリューションは、IPv6のいくつかの特性の使用に依存しています（暗号化されたアドレス（CGA）[RFC3972]の使用など）。これはMPTCPのコンテキストでは使用できません。
o As opposed to MPTCP, MIPv6 RO does not have connection-state-information, including sequence numbers, port numbers that could be leveraged to provide security in some form.
o MPTCPとは対照的に、MIPV6 ROには、シーケンス番号、何らかの形でセキュリティを提供するために活用できるポート番号など、接続状態情報がありません。
In the Shim6 [RFC5533] design, similar issues related to address agility were considered and a threat analysis was also performed [RFC4218]. The analysis performed for Shim6 also largely applies to the MPTCP context, the main differences being:
SHIM6 [RFC5533]設計では、アドレス俊敏性に関連する同様の問題が考慮され、脅威分析も実施されました[RFC4218]。SHIM6に対して実行された分析は、MPTCPコンテキストにも主に適用されます。主な違いは次のとおりです。
o The Shim6 protocol is a layer 3 protocol so all the communications involving the target address are at stake; in MPTCP, the impact can be limited to a single TCP connection.
o SHIM6プロトコルはレイヤー3プロトコルであるため、ターゲットアドレスを含むすべての通信が危機にatしています。MPTCPでは、影響は単一のTCP接続に制限できます。
o Similar to MIPv6 RO, Shim6 only uses IPv6 addresses as identifiers and leverages on some of their properties to provide the security, such as relying on CGA or Hash-Based Addresses (HBA) [RFC5535], which is not possible in the MPTCP case where IPv4 addresses must be supported.
o MIPV6 ROと同様に、SHIM6は、CGAまたはハッシュベースのアドレス（HBA）[RFC5535]に依存するなど、セキュリティを提供するために、一部のプロパティの識別子としてIPv6アドレスとレバレッジとしてのみ使用します。IPv4アドレスをサポートする必要があります。
o Similar to MIPv6 RO, Shim6 does not have a connection-state-information, including sequence numbers, port that could be leveraged to provide security in some form.
o MIPV6 ROと同様に、SHIM6には、シーケンス番号、何らかの形でセキュリティを提供するために活用できるポートを含む接続状態情報がありません。
Stream Control Transmission Protocol (SCTP) [RFC4960]is a transport protocol that supports multiple addresses per endpoint and the security implications are very close to the ones of MPTCP. A security analysis, identifying a set of attacks and proposed solutions was performed in [RFC5062]. The results of this analysis apply directly to the case of MPTCP. However, the analysis was performed after the base SCTP was designed and the goal of the document was essentially to improve the security of SCTP. As such, the document is very specific to the actual SCTP specification and relies on the SCTP messages and behavior to characterize the issues. While some them can be translated to the MPTCP case, some may be caused by the specific behavior of SCTP.
ストリーム制御伝送プロトコル（SCTP）[RFC4960]は、エンドポイントごとの複数のアドレスをサポートするトランスポートプロトコルであり、セキュリティへの影響はMPTCPのものに非常に近いものです。セキュリティ分析、一連の攻撃と提案されたソリューションの特定が[RFC5062]で実行されました。この分析の結果は、MPTCPの場合に直接適用されます。ただし、ベースSCTPが設計された後、分析は実行され、ドキュメントの目標は基本的にSCTPのセキュリティを改善することでした。そのため、ドキュメントは実際のSCTP仕様に非常に固有であり、問題を特徴付けるSCTPメッセージと動作に依存しています。それらはMPTCPケースに翻訳できるものもありますが、一部はSCTPの特定の動作によって引き起こされる可能性があります。
So, the conclusion is that while there is significant amount of previous work that is closely related, and it can and will be used it as a basis for this analysis, there is a set of characteristics that are specific to MPTCP that grant the need for a specific analysis for MPTCP. The goal of this analysis is to help MPTCP designers to include a set of security mechanisms that prevent the introduction of new vulnerabilities to the Internet due to the adoption of MPTCP.
したがって、結論は、密接に関連している以前の作業のかなりの量があり、この分析の基礎として使用できるか、使用することができます。MPTCPの特定の分析。この分析の目標は、MPTCP設計者がMPTCPの採用によりインターネットへの新しい脆弱性の導入を妨げる一連のセキュリティメカニズムを含めるのを支援することです。
The goal of this document is to serve as input for MPTCP designers to properly take into account the security issues. As such, the analysis cannot be performed for a specific MPTCP specification, but must be a general analysis that applies to the widest possible set of MPTCP designs. In order to do that, the fundamental features that any MPTCP must provide are identified and only those are assumed while performing the security analysis. In some cases, there is a design choice that significantly influences the security aspects of the resulting protocol. In that case, both options are considered.
このドキュメントの目標は、MPTCPデザイナーがセキュリティの問題を適切に考慮に入れるための入力として機能することです。そのため、特定のMPTCP仕様では分析を実行することはできませんが、MPTCP設計の可能な限り広範囲に適用される一般的な分析でなければなりません。それを行うために、MPTCPが提供する必要がある基本的な機能が特定され、セキュリティ分析の実行中はそれらのみが想定されます。場合によっては、結果のプロトコルのセキュリティの側面に大きな影響を与える設計選択があります。その場合、両方のオプションが考慮されます。
It is assumed that any MPTCP will behave in the case of a single address per endpoint as TCP. This means that an MPTCP connection will be established by using the TCP 3-way handshake and will use a single address pair.
MPTCPは、TCPとしてエンドポイントごとに単一のアドレスの場合に動作すると想定されています。これは、TCP 3ウェイハンドシェイクを使用してMPTCP接続が確立され、単一のアドレスペアを使用することを意味します。
The addresses used for the establishment of the connection do have a special role in the sense that this is the address used as identifier by the upper layers. The address used as destination address in the SYN packet is the address that the application is using to identify the peer and has been obtained either through the DNS (with or without DNS Security (DNSSEC) validation) or passed by a referral or manually introduced by the user. As such, the initiator does have a certain amount of trust in the fact that it is establishing a communication with that particular address. If due to MPTCP, packets end up being delivered to an alternative address, the trust that the initiator has placed on that address would be deceived. In any case, the adoption of MPTCP necessitates a slight evolution of the traditional TCP trust model, in that the initiator is additionally trusting the peer to provide additional addresses that it will trust to the same degree as the original pair. An application or implementation that cannot trust the peer in this way should not make use of multiple paths.
接続の確立に使用されるアドレスは、これが上層によって識別子として使用されるアドレスであるという意味で特別な役割を持っています。Synパケットの宛先アドレスとして使用されるアドレスは、アプリケーションがピアを識別するために使用しているアドレスであり、DNS（DNSセキュリティ（DNSSEC）検証の有無にかかわらず）または紹介によって渡されたか、手動で導入されたDNSを介して取得されています。ユーザー。そのため、イニシエーターは、その特定の住所とのコミュニケーションを確立しているという事実にある程度の信頼を持っています。MPTCPのおかげで、パケットが代替アドレスに配信されることになります。イニシエーターがそのアドレスに置いた信頼は欺かれます。いずれにせよ、MPTCPの採用には、従来のTCPトラストモデルのわずかな進化が必要です。イニシエーターは、元のペアと同じ程度に信頼できる追加のアドレスを提供するためにピアをさらに信頼しているからです。この方法でピアを信頼できないアプリケーションまたは実装は、複数のパスを使用してはなりません。
During the 3-way handshake, the sequence number will be synchronized for both ends, as in regular TCP. It is assumed that an MPTCP connection will use a single sequence number for the data, even if the data is exchanged through different paths, as MPTCP provides an in-order delivery service of bytes
3方向の握手中、通常のTCPのように、シーケンス番号は両端に対して同期されます。MPTCPがバイトの順序配信サービスを提供するため、データが異なるパスを介して交換された場合でも、MPTCP接続はデータに単一のシーケンス番号を使用すると想定されています。
Once the connection is established, the MPTCP extensions can be used to add addresses for each of the endpoints. This is achieved by each end sending a control message containing the additional address(es). In order to associate the additional address to an ongoing connection, the connection needs to be identified. It is assumed that the connection can be identified by the 4-tuple of source address, source port, destination address, destination port used for the establishment of the connection. So, at least, the control message that will convey the additional address information can also contain the 4-tuple in order to inform about what connection the address belong to (if no other connection identifier is defined). There are two different ways to convey address information:
接続が確立されると、MPTCP拡張機能を使用して、各エンドポイントのアドレスを追加できます。これは、追加のアドレスを含むコントロールメッセージを送信することによって達成されます。追加のアドレスを継続的な接続に関連付けるには、接続を特定する必要があります。接続は、接続の確立に使用される4項、ソースポート、宛先アドレス、宛先ポートによって識別できると想定されています。したがって、少なくとも、追加のアドレス情報を伝えるコントロールメッセージには、アドレスが属する接続を通知するために4タプルを含めることもできます（他の接続識別子が定義されていない場合）。アドレス情報を伝える方法は2つあります。
o Explicit mode: the control message contain a list of addresses.
o 明示的なモード：コントロールメッセージにはアドレスのリストが含まれています。
o Implicit mode: the address added is the one included in the source address field of the IP header
o 暗黙モード：追加されたアドレスは、IPヘッダーのソースアドレスフィールドに含まれるものです
These two modes have different security properties for some type of attacks. The explicit mode seems to be the more vulnerable to abuse. The implicit mode may benefit from forms of ingress filtering security, which would reduce the possibility of an attacker to add any arbitrary address to an ongoing connection. However, ingress filtering deployment is far from universal, and it is unwise to rely on it as a basis for the protection of MPTCP.
これらの2つのモードには、ある種の攻撃に対して異なるセキュリティプロパティがあります。明示的なモードは、虐待に対してより脆弱であるようです。暗黙的なモードは、イングレスフィルタリングセキュリティの形式から恩恵を受ける可能性があり、攻撃者が進行中の接続に任意のアドレスを追加する可能性を減らすでしょう。ただし、イングレスフィルタリングの展開は普遍的ではなく、MPTCPの保護のために基づいて依存することは賢明ではありません。
Further consideration regarding the interaction between ingress filtering and implicit mode signaling is needed in the case that an address that is no longer available from the MPTCP connection is removed. A host attached to a network that performs ingress filtering and using implicit signaling would not be able to remove an address that is no longer available (either because of a failure or due to a mobility event) from an ongoing MPTCP connection.
MPTCP接続から利用できなくなったアドレスが削除されている場合、イングレスフィルタリングと暗黙モードシグナル伝達との相互作用に関するさらなる考慮事項が必要です。イングレスフィルタリングを実行し、暗黙的なシグナル伝達を使用するネットワークに接続されているホストは、進行中のMPTCP接続から（失敗またはモビリティイベントのため）利用できなくなったアドレスを削除することはできません。
It is assumed that MPTCP will use all the address pairs that it has available for sending packets, and that it will distribute the load based on congestion among the different paths.
MPTCPは、パケットの送信に利用できるすべてのアドレスペアを使用し、異なるパス間の混雑に基づいて負荷を分配すると想定されています。
The first type of attacks that are introduced by address agility are the flooding (or bombing) attacks. The setup for this attack is depicted in the following figure:
住所の俊敏性によって導入される最初のタイプの攻撃は、洪水（または爆撃）攻撃です。この攻撃のセットアップは、次の図に示されています。
+--------+ (step 1) +------+
|Attacker| ------------------------- |Source|
| A |IPA IPS| S |
+--------+ /+------+
/
(step 2) /
/
v IPT
+------+
|Target|
| T |
+------+
The scenario consists of an Attacker A who has an IP address IPA. A server that can generate a significant amount of traffic (such as a streaming server), called source S and that has IP address IPS. Target T has an IP address IPT.
シナリオは、IPアドレスIPAを持っている攻撃者Aで構成されています。ソースSと呼ばれるかなりの量のトラフィック（ストリーミングサーバーなど）を生成できるサーバー。ターゲットTにはIPアドレスIPTがあります。
In step 1 of this attack, the Attacker A establishes an MPTCP connection with the source of the traffic server S and starts downloading a significant amount of traffic. The initial connection only involves one IP address per endpoint, IPA and IPS. Once the download is on course, in step 2 of the attack, the Attacker A adds IPT as one of the available addresses for the communication. How the additional address is added depends on the MPTCP address management mode. In explicit address management, the Attacker A only needs to send a signaling packet conveying address IPT. In implicit mode, the Attacker A would need to send a packet with IPT as the source address. Depending on whether ingress filtering is deployed and the location of the attacker, it may or may not be possible for the attacker to send such a packet. At this stage, the MPTCP connection still has a single address for the Source S, i.e., IPS, but has two addresses for the Attacker A, IPA, and IPT. The attacker now attempts to get the Source S to send the traffic of the ongoing download to the Target T IP address, i.e., IPT. The attacker can do that by pretending that the path between IPA and IPT is congested but that the path between IPS and IPT is not. In order to do that, it needs to send ACKs for the data that flows through the path between IPS and IPT and not send ACKs for the data that is sent to IPA. The details of this will depend on how the data sent through the different paths is ACKed. One possibility is that ACKs for the data sent using a given address pair should come in packets containing the same address pair. If so, the attacker would need to send ACKs using packets containing IPT as the source address to keep the attack flowing. This may or may not be possible depending on the deployment of ingress filtering and the location of the attacker. The attacker would also need to guess the sequence number of the data being sent to the Target. Once the attacker manages to perform these actions, the attack is on place and the download will hit the target. In this type of attack, the Source S still thinks it is sending packets to the Attacker A while in reality it is sending the packet to Target T.
この攻撃のステップ1では、攻撃者AがトラフィックサーバーSのソースとのMPTCP接続を確立し、かなりの量のトラフィックのダウンロードを開始します。初期接続には、エンドポイントごとに1つのIPアドレス、IPA、IPSのみが含まれます。攻撃のステップ2で、ダウンロードがコースに登場すると、攻撃者Aはコミュニケーションのために利用可能なアドレスの1つとしてIPTを追加します。追加のアドレスの追加方法は、MPTCPアドレス管理モードによって異なります。明示的なアドレス管理では、攻撃者Aは、アドレスIPTを伝える信号パケットを送信するだけです。暗黙的なモードでは、攻撃者AはソースアドレスとしてIPTを含むパケットを送信する必要があります。イングレスフィルタリングが展開されているかどうか、および攻撃者の場所に応じて、攻撃者がそのようなパケットを送信することが可能である場合とできない場合があります。この段階では、MPTCP接続には、ソースS、つまりIPSの単一のアドレスがまだありますが、攻撃者A、IPA、およびIPTの2つのアドレスがあります。攻撃者は、進行中のダウンロードのトラフィックをターゲットT IPアドレス、つまりIPTに送信するようにソースSを取得しようとします。攻撃者は、IPAとIPTの間のパスが混雑しているが、IPSとIPTの間のパスはそうではないとふりをすることでそれを行うことができます。そのためには、IPSとIPTの間のパスを流れるデータにACKを送信する必要があり、IPAに送信されるデータにACKを送信しません。この詳細は、異なるパスを介して送信されるデータがどのようにackedされているかによって異なります。1つの可能性は、特定のアドレスペアを使用して送信されたデータのACKが同じアドレスペアを含むパケットに入れる必要があることです。その場合、攻撃者は、IPTを含むパケットをソースアドレスとして使用してACKを送信して、攻撃を流し続ける必要があります。これは、イングレスフィルタリングの展開と攻撃者の位置に応じて、可能である場合とできない場合があります。また、攻撃者は、ターゲットに送信されるデータのシーケンス番号を推測する必要があります。攻撃者がこれらのアクションを実行すると、攻撃は場所にあり、ダウンロードはターゲットに到達します。このタイプの攻撃では、ソースSは、実際にはターゲットTにパケットを送信しているため、攻撃者にパケットを送信していると考えています。
Once the traffic from the Source S start hitting the Target T, the target will react. Since the packets are likely to belong to a non-existent TCP connection, the Target T will issue RST packets. It is relevant to understand how MPTCP reacts to incoming RST packets. It seems that the at least the MPTCP that receives a RST packet should terminate the packet exchange corresponding to the particular address pair (maybe not the complete MPTCP connection, but at least it should not send more packets with the address pair involved in the RST packet). However, if the attacker, before redirecting the traffic has managed to increase the window size considerably, the flight size could be enough to impose a significant amount of traffic to the Target node. There is a subtle operation that the attacker needs to achieve in order to launch a significant attack. On the one hand, it needs to grow the window enough so that the flight size is big enough to cause enough effect; on the other hand, the attacker needs to be able to simulate congestion on the IPA-IPS path so that traffic is actually redirected to the alternative path without significantly reducing the window. This will heavily depend on how the coupling of the windows between the different paths works, in particular how the windows are increased. Some designs of the congestion control window coupling could render this attack ineffective. If the MPTCP requires performing slow start per subflow, then the flooding will be limited by the slow-start initial window size.
ソースSからのトラフィックがターゲットTにヒットし始めると、ターゲットが反応します。パケットは存在しないTCP接続に属する可能性が高いため、ターゲットTはRSTパケットを発行します。MPTCPが着信RSTパケットにどのように反応するかを理解することは関連します。少なくともRSTパケットを受信するMPTCPは、特定のアドレスペアに対応するパケット交換を終了する必要があるようです（完全なMPTCP接続ではないかもしれませんが、少なくともRSTパケットに含まれるアドレスペアでこれ以上のパケットを送信しないでください）。ただし、攻撃者がトラフィックをリダイレクトする前にウィンドウサイズを大幅に増やすことができた場合、飛行サイズはターゲットノードにかなりの量のトラフィックを課すのに十分である可能性があります。重要な攻撃を開始するために攻撃者が達成する必要がある微妙な手術があります。一方では、フライトサイズが十分な効果をもたらすのに十分な大きさになるように、窓を十分に成長させる必要があります。一方、攻撃者は、IPA-IPSパスの混雑をシミュレートできるようにする必要があり、実際にトラフィックがウィンドウを大幅に削減することなく代替パスにリダイレクトされるようにします。これは、異なるパス間のウィンドウの結合がどのように機能するか、特にウィンドウの増加方法に大きく依存します。輻輳制御ウィンドウの結合のいくつかの設計では、この攻撃を無効にする可能性があります。MPTCPがサブフローごとにスロースタートを実行する必要がある場合、洪水はスロースタートの初期ウィンドウサイズによって制限されます。
Previous protocols, such as MIPv6 RO and SCTP, that have to deal with this type of attacks have done so by adding a reachability check before actually sending data to a new address. The solution used in other protocols would include the Source S to explicitly asking the host sitting in the new address (the Target T sitting in IPT) whether it is willing to accept packets from the MPTCP connection identified by the 4-tuple IPA, port A, IPS, port S. Since this is not part of the established connection that Target T has, T would not accept the request and Source S would not use IPT to send packets for this MPTCP connection. Usually, the request also includes a nonce that cannot be guessed by the Attacker A so that it cannot fake the reply to the request easily. In the case of SCTP, it sends a message with a 64- bit nonce (in a HEARTBEAT).
MIPV6 ROやSCTPなどの以前のプロトコルは、このタイプの攻撃に対処する必要があるため、実際にデータを新しいアドレスに送信する前に到達可能性チェックを追加することでそうしました。他のプロトコルで使用されるソリューションには、新しいアドレスに座っているホスト（IPTに座っているターゲットT）に明示的に尋ねるソースSが含まれます。、IPS、ポートS。これはターゲットTが持っている確立された接続の一部ではないため、Tはリクエストを受け入れず、ソースSはこのMPTCP接続にパケットを送信するためにIPTを使用しません。通常、リクエストには、リクエストへの返信を簡単に偽造できないように、攻撃者Aが推測できないNONCEも含まれています。SCTPの場合、64ビットのnonce（ハートビート）でメッセージを送信します。
One possible approach to do this reachability test would be to perform a 3-way handshake for each new address pair that is going to be used in an MPTCP connection. While there are other reasons for doing this (such as NAT traversal), such approach would also act as a reachability test and would prevent the flooding attacks described in this section.
この到達可能性テストを行うための1つの可能なアプローチは、MPTCP接続で使用される新しいアドレスペアごとに3方向の握手を実行することです。これを行う他の理由（Nat Traversalなど）がありますが、そのようなアプローチもリーチ可能性テストとして機能し、このセクションで説明されている洪水攻撃を防ぎます。
Another type of flooding attack that could potentially be performed with MPTCP is one where the attacker initiates a communication with a peer and includes a long list of alternative addresses in explicit mode. If the peer decides to establish subflows with all the available addresses, the attacker has managed to achieve an amplified attack, since by sending a single packet containing all the alternative addresses, it triggers the peer to generate packets to all the destinations.
MPTCPで実行される可能性のある別のタイプの洪水攻撃は、攻撃者がピアとの通信を開始し、明示的なモードでの代替アドレスの長いリストを含む場所です。ピアが利用可能なすべてのアドレスでサブフローを確立することを決定した場合、攻撃者はすべての代替アドレスを含む単一のパケットを送信することにより、ピアをトリガーしてすべての宛先にパケットを生成するため、攻撃者が増幅された攻撃を達成することができました。
The hijacking attacks essentially use the MPTCP address agility to allow an attacker to hijack a connection. This means that the victim of a connection thinks that it is talking to a peer, while it is actually exchanging packets with the attacker. In some sense, it is the dual of the flooding attacks (where the victim thinks it is exchanging packets with the attacker but in reality is sending the packets to the target).
ハイジャック攻撃は、基本的にMPTCPアドレスの俊敏性を使用して、攻撃者が接続をハイジャックできるようにします。これは、接続の犠牲者が実際に攻撃者とパケットを交換している間、ピアと話していると考えていることを意味します。ある意味では、それは洪水攻撃の二重です（被害者は、攻撃者とパケットを交換していると考えていますが、実際にはターゲットにパケットを送信しています）。
The scenario for a hijacking attack is described in the next figure.
ハイジャック攻撃のシナリオについては、次の図で説明します。
+------+ +------+
| Node | ------------------------- | Node |
| 1 |IP1 IP2| 2 |
+------+ /+------+
/
/
/
v IPA
+--------+
|Attacker|
| A |
+--------+
An MPTCP connection is established between Node 1 and Node 2. The connection is using only one address per endpoint, IP1 and IP2. The attacker then launches the hijacking attack by adding IPA as an additional address for Node 1. There is not much difference between explicit or implicit address management, since, in both cases, the Attacker A could easily send a control packet adding the address IPA, either as control data or as the source address of the control packet. In order to be able to hijack the connection, the attacker needs to know the 4-tuple that identifies the connection, including the pair of addresses and the pair of ports. It seems reasonable to assume that knowing the source and destination IP addresses and the port of the server side is fairly easy for the attacker. Learning the port of the client (i.e., of the initiator of the connection) may prove to be more challenging. The attacker would need to guess what the port is or to learn it by intercepting the packets. Assuming that the attacker can gather the 4-tuple and issue the message adding IPA to the addresses available for the MPTCP connection, then the Attacker A has been able to participate in the communication. In particular:
MPTCP接続はノード1とノード2の間に確立されます。接続は、エンドポイントごとに1つのアドレス、IP1とIP2のみを使用しています。その後、攻撃者は、ノード1の追加アドレスとしてIPAを追加することにより、ハイジャック攻撃を開始します。明示的または暗黙的なアドレス管理には大きな違いはありません。どちらの場合も、攻撃者Aはコントロールパケットを簡単に送信してアドレスIPAを追加することができます。コントロールデータとして、またはコントロールパケットのソースアドレスとして。接続をハイジャックできるようにするために、攻撃者は、アドレスのペアとポートのペアを含む接続を識別する4タプルを知る必要があります。ソースと宛先のIPアドレスとサーバー側のポートを知ることは、攻撃者にとってかなり簡単であると想定するのが合理的に思えます。クライアントのポートを学習する（つまり、接続のイニシエーター）がより困難であることが判明するかもしれません。攻撃者は、ポートが何であるかを推測するか、パケットを傍受してそれを学習する必要があります。攻撃者が4タプルを収集し、MPTCP接続で利用可能なアドレスにIPAを追加するメッセージを発行できると仮定すると、攻撃者Aはコミュニケーションに参加することができました。特に：
o Segments flowing from the Node 2: Depending how the usage of addresses is defined, Node 2 will start using IPA to send data to. In general, since the main goal is to achieve multipath capabilities, it can be assumed that unless there are already many IP address pairs in use in the MPTCP connection, Node 2 will start sending data to IPA. This means that part of the data of the communication will reach the attacker but probably not all of it. This already has negative effects, since Node 1 will not receive all the data from Node 2. Moreover, from the application perspective, this would result in a Denial-of-Service (DoS) attack, since the byte flow will stop waiting for the missing data. However, it is not enough to achieve full hijacking of the connection, since part of data will be still delivered to IP1, so it would reach Node 1 and not the attacker. In order for the attacker to receive all the data of the MPTCP connection, the attacker must somehow remove IP1 of the set of available addresses for the connection. In the case of implicit address management, this operation is likely to imply sending a termination packet with IP1 as source address, which may or may not be possible for the attacker depending on whether ingress filtering is in place and the location of the attacker. If explicit address management is used, then the attacker will send a remove address control packet containing IP1. Once IP1 is removed, all the data sent by Node 2 will reach the attacker and the incoming traffic has been hijacked.
o ノード2から流れるセグメント：アドレスの使用方法の定義方法に応じて、ノード2はIPAを使用してデータを送信し始めます。一般に、主な目標はマルチパス機能を達成することであるため、MPTCP接続で使用されている多くのIPアドレスペアが既にある場合を除き、ノード2はIPAにデータの送信を開始すると想定できます。これは、コミュニケーションのデータの一部が攻撃者に届くことを意味しますが、おそらくすべてではありません。ノード1はノード2からすべてのデータを受信しないため、すでにマイナスの効果があります。さらに、アプリケーションの観点から、これによりバイトフローが待機を停止するため、サービス拒否（DOS）攻撃が発生します。欠落データ。ただし、データの一部がまだIP1に配信されるため、接続の完全なハイジャックを達成するだけでは不十分なため、攻撃者ではなくノード1に到達します。攻撃者がMPTCP接続のすべてのデータを受信するためには、攻撃者は、接続の利用可能なアドレスのセットのIP1を何らかの形で削除する必要があります。暗黙のアドレス管理の場合、この操作は、IP1を使用した終端パケットをソースアドレスとして送信することを意味する可能性があります。これは、イングレスフィルタリングが整っているかどうかと攻撃者の位置に応じて攻撃者にとって可能である場合とできない場合があります。明示的なアドレス管理を使用すると、攻撃者はIP1を含む削除アドレス制御パケットを送信します。IP1が削除されると、Node 2から送信されたすべてのデータが攻撃者に届き、着信トラフィックがハイジャックされます。
o Segments flowing to the Node 2: As soon as IPA is accepted by Node 2 as part of the address set for the MPTCP connection, the attacker can send packets using IPA, and those packets will be considered as part of MPTCP connection by Node 2. This means that the attacker will be able to inject data into the MPTCP connection, so from this perspective, the attacker has hijacked part of the outgoing traffic. However, Node 1 would still be able to send traffic that will be received by Node 2 as part of the MPTCP connection. This means that there will be two sources of data, i.e., Node 1 and the attacker, potentially preventing the full hijacking of the outgoing traffic by the attacker. In order to achieve a full hijacking, the attacker would need to remove IP1 from the set of available addresses. This can be done using the same techniques described in the previous paragraph.
o ノード2に流れるセグメント：MPTCP接続のアドレスセットの一部としてIPAがノード2によって受け入れられるとすぐに、攻撃者はIPAを使用してパケットを送信でき、それらのパケットはノード2によるMPTCP接続の一部と見なされます。これは、攻撃者がMPTCP接続にデータを注入できることを意味するため、この観点から、攻撃者は発信トラフィックの一部をハイジャックしました。ただし、ノード1は、MPTCP接続の一部としてノード2が受信するトラフィックを送信することができます。これは、2つのデータソース、つまりノード1と攻撃者が存在することを意味し、攻撃者による発信トラフィックの完全なハイジャックを防ぐ可能性があります。完全なハイジャックを達成するには、攻撃者は利用可能なアドレスのセットからIP1を削除する必要があります。これは、前の段落で説明したのと同じ手法を使用して実行できます。
A related attack that can be achieved using similar techniques would be an MiTM attack. The scenario for the attack is depicted in the figure below.
同様の手法を使用して達成できる関連攻撃は、MITM攻撃です。攻撃のシナリオは、下の図に示されています。
+------+ +------+
| Node | --------------- | Node |
| 1 |IP1 IP2| 2 |
+------+ \ /+------+
\ /
\ /
\ /
v IPA v
+--------+
|Attacker|
| A |
+--------+
There is an established connection between Node 1 and Node 2. The Attacker A will use the MPTCP address agility capabilities to place itself as a MiTM. In order to do so, it will add IP address IPA as an additional address for the MPTCP connection on both Node 1 and Node 2. This is essentially the same technique described earlier in this section, only that it is used against both nodes involved in the communication. The main difference is that in this case, the attacker can simply sniff the content of the communication that is forwarded through it and in turn forward the data to the peer of the communication. The result is that the attacker can place himself in the middle of the communication and sniff part of the traffic unnoticed. Similar considerations about how the attacker can manage to get to see all the traffic by removing the genuine address of the peer apply.
ノード1とノード2の間には確立された接続があります。攻撃者Aは、MPTCPアドレスの俊敏性機能を使用して、MITMとしてそれ自体を配置します。そうするために、IPアドレスIPAをノード1とノード2の両方のMPTCP接続の追加アドレスとして追加します。これは、本質的にこのセクションで前述した手法と同じです。コミュニケーション。主な違いは、この場合、攻撃者は、通信を介して転送される通信のコンテンツを単純に嗅ぎ、データを通信のピアに転送できることです。その結果、攻撃者はコミュニケーションの真ん中に自分自身を配置し、気付かれていないトラフィックの一部を嗅ぐことができます。ピアの本物のアドレスを削除することにより、攻撃者がすべてのトラフィックを見ることができる方法についての同様の考慮事項。
A simple way to prevent off-path attackers from launching hijacking attacks is to provide security for the control messages that adds and removes addresses by the usage of a cookie. In this type of approaches, the peers involved in the MPTCP connection agree on a cookie that is exchanged in plaintext during the establishment of the connection and that needs to be presented in every control packet that adds or removes an address for any of the peers. The result is that the attacker needs to know the cookie in order to launch any of the hijacking attacks described earlier. This implies that off-path attackers can no longer perform the hijacking attacks and that only on-path attackers can do so, so one may consider a cookie-based approach to secure MPTCP connection results in similar security to current TCP. While it is close, it is not entirely true.
オフパスの攻撃者がハイジャック攻撃を開始するのを防ぐ簡単な方法は、Cookieの使用によってアドレスを追加および削除する制御メッセージのセキュリティを提供することです。このタイプのアプローチでは、MPTCP接続に関与するピアは、接続の確立中にプレーンテキストで交換されるCookieに同意します。その結果、攻撃者は、前述のハイジャック攻撃を開始するためにCookieを知る必要があります。これは、オフパスの攻撃者がハイジャック攻撃を実行できなくなり、パス上の攻撃者のみがそうすることができることを意味するため、MPTCP接続を保護するためのCookieベースのアプローチを検討することができます。近いですが、完全に真実ではありません。
The main difference between the security of an MPTCP secured through cookies and the current TCP is the time-shifted attacks. As has been described earlier, a time-shifted attack is one where the attacker is along the path during a period of time, and then moves away but the effects of the attack still remain, after the attacker is long gone. In the case of an MPTCP secured through the usage of cookies, the attacker needs to be along the path until the cookie is exchanged. After the attacker has learned the cookie, it can move away from the path and can still launch the hijacking attacks described in the previous section.
Cookieを介して保護されたMPTCPのセキュリティと現在のTCPの主な違いは、タイムシフト攻撃です。前に説明したように、タイムシフトされた攻撃は、攻撃者が一定期間に道に沿っている場所であり、その後攻撃者がいなくなった後も攻撃の影響はまだ残っています。Cookieの使用によって確保されたMPTCPの場合、攻撃者はCookieが交換されるまでパスに沿っている必要があります。攻撃者がCookieを学んだ後、パスから離れることができ、前のセクションで説明したハイジャック攻撃を起動することができます。
There are several types of approaches that provide some protection against hijacking attacks and that are vulnerable to some forms of time-shifted attacks. A general taxonomy of solutions and the residual threats for each type is presented next:
ハイジャック攻撃に対してある程度の保護を提供するアプローチにはいくつかの種類があり、いくつかの形態のタイムシフト攻撃に対して脆弱です。ソリューションの一般的な分類法と各タイプの残留脅威が次に提示されます。
o Cookie-based solution: As it has been described earlier, one possible approach is to use a cookie that is sent in cleartext in every MPTCP control message that adds a new address to the existing connection. The residual threat in this type of solution is that any attacker that can sniff any of these control messages will learn the cookie and will be able to add new addresses at any given point in the lifetime of the connection. Moreover, the endpoints will not detect the attack since the original cookie is being used by the attacker. Summarizing, the vulnerability window of this type of attacks includes all the flow establishment exchanges and it is undetectable by the endpoints.
o Cookieベースのソリューション：前述のように、1つの考えられるアプローチは、既存の接続に新しいアドレスを追加するすべてのMPTCPコントロールメッセージでクリアテキストで送信されるCookieを使用することです。このタイプのソリューションの残留脅威は、これらの制御メッセージのいずれかを嗅ぐことができる攻撃者がCookieを学習し、接続の寿命の任意のポイントで新しいアドレスを追加できることです。さらに、元のCookieが攻撃者によって使用されているため、エンドポイントは攻撃を検出しません。要約すると、このタイプの攻撃の脆弱性ウィンドウには、すべてのフロー確立交換が含まれており、エンドポイントによって検出できません。
o Shared secret exchanged in plaintext: An alternative option that is more secure than the cookie-based approach is to exchange a key in cleartext during the establishment of the first subflow and then validate the following subflows by using a keyed Hashed Message Authentication Code (HMAC) signature using the shared key. This solution would be vulnerable to attackers sniffing the message exchange for the establishment of the first subflow, but after that, the shared key is not transmitted any more, so the attacker cannot learn it through sniffing any other message. Unfortunately, in order to be compatible with NATs (see analysis below) even though this approach includes a keyed HMAC signature, this signature cannot cover the IP address that is being added. This means that this type of approaches are also vulnerable to integrity attacks of the exchanged messages. This means that even though the attacker cannot learn the shared key by sniffing the subsequent subflow establishment, the attacker can modify the subflow establishment message and change the address that is being added. So, the vulnerability window for confidentially to the shared key is limited to the establishment of the first subflow, but the vulnerability window for integrity attacks still includes all the subflow establishment exchanges. These attacks are still undetectable by the endpoints. The SCTP security falls in this category.
o Plantextで交換された共有秘密：Cookieベースのアプローチよりも安全な代替オプションは、最初のサブフローの確立中にクリアテキストでキーを交換し、キー付きハッシュメッセージ認証コード（HMAC）を使用して次のサブフローを検証することです。共有キーを使用した署名。このソリューションは、最初のサブフローを確立するためのメッセージ交換を嗅ぐ攻撃者に対して脆弱ですが、その後、共有キーはそれ以上送信されないため、攻撃者は他のメッセージを嗅ぐことでそれを学ぶことができません。残念ながら、NATと互換性があるため（以下の分析を参照）、このアプローチにはキー付きHMAC署名が含まれていても、この署名は追加されているIPアドレスをカバーすることはできません。これは、このタイプのアプローチが交換されたメッセージの整合性攻撃に対しても脆弱であることを意味します。これは、攻撃者がその後のサブフロー確立を嗅ぐことで共有キーを学ぶことができない場合でも、攻撃者はサブフロー確立メッセージを変更し、追加されているアドレスを変更できることを意味します。したがって、共有キーに秘密にするための脆弱性ウィンドウは、最初のサブフローの確立に限定されますが、整合性攻撃の脆弱性ウィンドウには、すべてのサブフロー確立交換が含まれています。これらの攻撃は、エンドポイントによってまだ検出できません。SCTPセキュリティはこのカテゴリに分類されます。
o Strong crypto anchor exchange: Another approach that could be used would be to exchange some strong crypto anchor while the establishment of the first subflow, such as a public key or a hash chain anchor. Subsequent subflows could be protected by using the crypto material associated to that anchor. An attacker in this case would need to change the crypto material exchanged in the connection establishment phase. As a result, the vulnerability window for forging the crypto anchor is limited to the initial connection establishment exchange. Similar to the previous case, due to NAT traversal considerations, the vulnerability window for integrity attacks include all the subflow establishment exchanges. Because the attacker needs to change the crypto anchor, this approach are detectable by the endpoints, if they communicate directly.
o 強力な暗号アンカー交換：使用できる別のアプローチは、公開キーやハッシュチェーンアンカーなどの最初のサブフローの確立中に、強力な暗号アンカーを交換することです。後続のサブフローは、そのアンカーに関連付けられた暗号材料を使用して保護できます。この場合の攻撃者は、接続確立段階で交換された暗号材料を変更する必要があります。その結果、暗号アンカーを鍛造するための脆弱性ウィンドウは、最初の接続確立交換に限定されます。以前のケースと同様に、NATトラバーサルの考慮事項により、整合性攻撃の脆弱性ウィンドウには、すべてのサブフロー確立交換が含まれます。攻撃者は暗号アンカーを変更する必要があるため、このアプローチは、直接通信する場合、エンドポイントによって検出可能です。
In order to be widely adopted, MPTCP must work through NATs. NATs are an interesting device from a security perspective. In terms of MPTCP, they essentially behave as an MiTM attacker. MPTCP's security goal is to prevent from any attacker to insert their addresses as valid addresses for a given MPTCP connection. But that is exactly what a NAT does: it modifies the addresses. So, if MPTCP is to work through NATs, MPTCP must accept address rewritten by NATs as valid addresses for a given session. The most direct corollary is that the MPTCP messages that add addresses in the implicit mode (i.e., the SYN of new subflows) cannot be protected against integrity attacks, since they must allow for NATs to change their addresses. This rules out any solution that would rely on providing integrity protection to prevent an attacker from changing the address used in a subflow establishment exchange. This implies that alternative creative mechanisms are needed to protect from integrity attacks to the MPTCP signaling that adds new addresses to a connection. It is far from obvious how one such creative approach could look like at this point.
広く採用されるためには、MPTCPはNATを介して作業する必要があります。NATは、セキュリティの観点から興味深いデバイスです。MPTCPに関しては、本質的にMITM攻撃者として振る舞います。MPTCPのセキュリティ目標は、攻撃者が特定のMPTCP接続の有効なアドレスとしてアドレスを挿入するのを防ぐことです。しかし、それはまさにNATが行うことです。アドレスを変更します。したがって、MPTCPがNATを介して作業する場合、MPTCPはNATによって書き換えられたアドレスを特定のセッションの有効なアドレスとして受け入れる必要があります。最も直接的な結果は、暗黙的なモード（つまり、新しいサブフローのSyn）にアドレスを追加するMPTCPメッセージを整合性攻撃から保護できないことです。これは、攻撃者がサブフローの確立交換で使用される住所を変更するのを防ぐために、整合性保護を提供することに依存するソリューションを排除します。これは、接続に新しいアドレスを追加するMPTCPシグナリングへの整合性攻撃から保護するために、代替の創造的メカニズムが必要であることを意味します。この時点で、そのような創造的なアプローチがどのように見えるかは明らかではありません。
In the case of explicit mode, you could protect the address included in the MPTCP option. Now the question is what address to include in the MPTCP option that conveys address information. If the address included is the address configured in the host interface and that interface is behind a NAT, the address information is useless, as the address is not actually reachable from the other end so there is no point in conveying it and even less in securing it. It would be possible to envision the usage of NAT traversal techniques, such as Session Traversal Utilities for NAT (STUN) to learn the address and port that the NAT has assigned and convey that information in a secure. While this is possible, it relies on using NAT traversal techniques and also tools to convey the address and the port in a secure manner.
明示的なモードの場合、MPTCPオプションに含まれるアドレスを保護できます。ここで、問題は、アドレス情報を伝えるMPTCPオプションにどのアドレスを含めるかです。アドレスがホストインターフェイスで構成されており、そのインターフェイスがNATの背後にあるアドレスである場合、アドレスは実際には反対側から到達できないため、アドレス情報は役に立たないため、それを伝えることにはポイントがなく、確保することはさらに少ないためです。それ。NAT（STUN）のセッショントラバーサルユーティリティなどのNATトラバーサルテクニックの使用が、NATがその情報を割り当てて伝達したアドレスとポートを学習して安全に伝えることを想定することが可能です。これは可能ですが、NATトラバーサルテクニックとツールを使用して、アドレスとポートを安全な方法で伝えることに依存しています。
The presented analysis shows that there is a tradeoff between the complexity of the security solution and the residual threats. After evaluating the different aspects in the MPTCP WG, the conclusions are as follows:
提示された分析は、セキュリティソリューションの複雑さと残留脅威の間にトレードオフがあることを示しています。MPTCP WGのさまざまな側面を評価した後、結論は次のとおりです。
MPTCP should implement some form of reachability check using a random nonce (e.g., TCP 3-way handshake) before adding a new address to an ongoing communication in order to prevent flooding attacks.
MPTCPは、洪水攻撃を防ぐために継続的な通信に新しいアドレスを追加する前に、ランダムなノンセ（TCP 3ウェイハンドシェイクなど）を使用して何らかの形の到達可能性チェックを実装する必要があります。
The default security mechanisms for MPTCP should be to exchange a key in cleartext in the establishment of the first subflow and then secure following address additions by using a keyed HMAC using the exchanged key.
MPTCPのデフォルトのセキュリティメカニズムは、最初のサブフローの確立でクリアテキストのキーを交換し、交換されたキーを使用してキー付きHMACを使用してアドレスの追加を確保することです。
MPTCP security mechanism should support using a pre-shared key to be used in the keyed HMAC, providing a higher level of protection than the previous one.
MPTCPセキュリティメカニズムは、キー付きHMACで使用される事前共有キーを使用してサポートし、前のものよりも高いレベルの保護を提供する必要があります。
A mechanism to prevent replay attacks using these messages should be provided, e.g., a sequence number protected by the HMAC.
これらのメッセージを使用したリプレイ攻撃を防ぐメカニズムを提供する必要があります。たとえば、HMACによって保護されたシーケンス番号。
The MPTCP should be extensible and it should be able to accommodate multiple security solutions, in order to enable the usage of more secure mechanisms if needed.
MPTCPは拡張可能である必要があり、必要に応じてより安全なメカニズムの使用を可能にするために、複数のセキュリティソリューションに対応できる必要があります。
This note contains a security analysis for MPTCP, so no further security considerations need to be described in this section.
このメモにはMPTCPのセキュリティ分析が含まれているため、このセクションで説明することは必要ありません。
Alan Ford - Roke Manor Research, Ltd.
アラン・フォード - ローク・マナー・リサーチ、Ltd。
Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen, Michael Scharf, Tim Shepard, Yoshifumi Nishida, Lars Eggert, Phil Eardley, Jari Arkko, David Harrington, Dan Romascanu, and Alexey Melnikov reviewed an earlier version of this document and provided comments to improve it.
ロルフ・ウィンター、ランドール・スチュワート、アンドリュー・マクドナルド、マイケル・トゥエクセン、マイケル・シャーフ、ティム・シェパード、ヨシフミ・ニシダ、ラース・エガート、フィル・アードリー、ジャリ・アークコ、デビッド・ハリントン、ダン・ロマスカヌ、アレクセイ・メルニコフは、この文書の以前のバージョンをレビューし、コメントを提供し、コメントを提供しましたそれを改善。
Mark Handley pointed out the problem with NATs and integrity protection of MPTCP signaling.
マーク・ハンドリーは、NATとMPTCPシグナル伝達の整合性保護に関する問題を指摘しました。
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnuloは、第7回のフレームワークプログラムに基づいて欧州委員会がサポートする研究プロジェクトであるTrilogyによって部分的に資金提供されています。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4225、2005年12月。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[RFC4218] Nordmark、E。およびT. Li、「IPv6 Multihoming Solutionsに関連する脅威」、RFC 4218、2005年10月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures", RFC 5062, September 2007.
[RFC5062] Stewart、R.、Tuexen、M。、およびG. Camarillo、「ストリーム制御伝送プロトコル（SCTP）および現在の対策に対するセキュリティ攻撃」、RFC 5062、2007年9月。
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[RFC5535] Bagnulo、M。、「ハッシュベースのアドレス（HBA）」、RFC 5535、2009年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmark、E。およびM. Bagnulo、「SHIM6：IPv6のレベル3マルチホミングシムプロトコル」、RFC 5533、2009年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[MPTCP-MULTIADDRESSED] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for Multipath Operation with Multiple Addresses", Work in Progress, October 2010.
[MPTCP-MultiAddressed] Ford、A.、Raiciu、C。、およびM. Handley、「複数のアドレスを備えたマルチパス操作のためのTCP拡張」、2010年10月、作業中。
Author's Address
著者の連絡先
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
Marcelo Bagnulo Universidad Carlos III de Madrid av。Universidad 30 Leganes、Madrid 28911スペイン
Phone: 34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es