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
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.
マルチ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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
マルチ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].
マルチパスTCPを達成するための複数の方法があります。通信の異なるセグメントは、経路選択のいくつかのフォームを指定するために、送信者を有効にすることによって、異なる経路を介して転送されるため、本質的に、必要とされるものです。ように異なる退出ポイントにトンネルを使用して、異なる次ホップの使用を含む、このような経路選択のための複数のオプションが存在します。分析の範囲は、このノートに含まれるエンドポイントごとに複数のIPアドレスの使用に依存し、それは異なる経路を表現する手段として、異なる送信元と宛先アドレスのペアを使用して特定のアプローチ、すなわちMPTCP、に制限されます。だから、このノートの残りの部分では、MPTCP式はマルチパスTCP [MPTCP-同報]のこのマルチ対処味を指します。
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と比較して、マルチアドレス支持体から得られた追加的な脆弱性に制限されます。脅威の完全なセットの完全な分析は、スコープの外に、明示的です。この分析の目的は、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では、パス上の攻撃者は、その上の盗聴、接続ハイジャックのman-in-the-middle（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.
しかし、（単一パス上の）攻撃者が完全なデータストリームの可視性を持っていないので、いくつかの現在のパス攻撃は、マルチパス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:
敏捷性に対処するために関連する問題のほとんどは深く分析し、[RFC3775]モバイルIPv6（MIPv6のRO）でのルート最適化サポートの文脈で理解されています。 [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.
MIPv6のRO中のOは、バインディングアドレスがMPTCPの場合、単一の接続がかかっている間、アドレスを含むすべての通信に影響を与えます。二つのアドレス間の結合をIP層で作成された場合、これは、それらのアドレスを伴うすべての接続に影響しますすることができますバインディング。追加アドレスは、現在進行中のTCPコネクションに追加された場合しかし、MPTCPに、追加のアドレスは/だけ同じアドレスがそれらの他の接続に使用されている場合でも、他の接続の手ではなく、接続に影響を与えることができます。結果は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.
MIPv6のRO中のO、接続が確立されてきた、それを通して元のアドレス（ホームアドレス）が常に利用可能であり、それがない場合には、通信が失われるという仮定があります。これは、モバイルノードの現在の場所にパケットを中継するために、信頼できるパーティ（ホームエージェント）上で活用することによって達成されます。アドレスペアのいずれかが使用できなくなっているので、常に動作して、元のアドレスのペアに活用することができないときMPTCPでは、通信回復力を提供するために、明示的な目標ではありません。
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セキュリティソリューションはMPTCPの文脈で使用できません（例えば、暗号化生成アドレス（CGA）[RFC3972]の使用など）のIPv6のいくつかの特徴の使用に依存しています。
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.
MPTCPとは対照的に、O、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プロトコルです。 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のみようMPTCPの場合には不可能である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.
MIPv6のROと同様にO、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の採用には、インターネットに新たな脆弱性の導入を防止するためのセキュリティメカニズムのセットが含まれるように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などのエンドポイントごとに単一のアドレスの場合で動作することが想定されます。これはMPTCP接続はTCP 3ウェイハンドシェイクを使用することによって設立され、単一のアドレスのペアを使用することを意味します。
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）検証なし）、または渡さ紹介することによって、または手動で導入されたアドレスでありますユーザー。このように、イニシエータは、それがその特定のアドレスとの通信を確立しているという事実に信頼の一定量を持っています。 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タプルをも含むことができます（他の接続識別子が定義されていない場合）に属しています。アドレス情報を伝えるために二つの異なる方法があります。
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と呼ばれ、それは、IPアドレスIPSがあります。ターゲット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接続を確立し、トラフィックのかなりの量のダウンロードを開始します。最初の接続はエンドポイントのみ、IPAおよびIPSに1つのIPアドレスを必要とします。ダウンロードは、攻撃のステップ2で、コースになると、攻撃者Aは、通信のために利用可能なアドレスの一つとして、IPTを追加します。追加のアドレスが追加されたどのようにMPTCPアドレス管理モードに依存します。明示的なアドレス管理では、攻撃者AはアドレスのみIPTを伝えるシグナリングパケットを送信する必要があります。暗黙のモードでは、攻撃者Aは、送信元アドレスとしてIPTでパケットを送信する必要があります。攻撃者がこのようなパケットを送信するためのイングレスフィルタリングが展開され、攻撃者の位置であるかどうかに応じて、または可能であってもなくてもよいです。この段階では、MPTCP接続がまだソースSのための単一のアドレス、すなわち、IPSを持っていますが、攻撃者A、IPA、およびIPTのための2つのアドレスを持っています。攻撃者は現在、ターゲットT IPアドレス、すなわち、IPTに現在進行中のダウンロードのトラフィックを送信するために、ソースSを取得しようとします。攻撃者は、IPAとIPTの間のパスが混雑しているが、IPSとIPTの間のパスがないことをことをふりをすることによってそれを行うことができます。そのためには、IPSとIPT間の経路を通って流れ、IPAに送信されたデータのためのACKを送信しないデータに対するACKを送信する必要があります。これの詳細については、異なる経路を介して送信されるデータがACKされている方法によって異なります。一つの可能性は、与えられたアドレス・ペアを使用して送信データのACKが同じアドレスペアを含むパケットに来るべきであることです。その場合、攻撃者は攻撃流れを維持するために、送信元アドレスとしてIPTを含むパケットを使用してACKを送信する必要があります。これは、または入力フィルタリングおよび攻撃者の位置の配置に応じて可能であってもなくてもよいです。攻撃者は、ターゲットに送信されるデータのシーケンス番号を推測する必要があります。攻撃者がこれらのアクションを実行するために管理したら、攻撃は場所にあり、ダウンロードには、目標を達成します。この種の攻撃では、ソースSは、まだ現実にはそれがターゲットTにパケットを送信している間、それは攻撃者Aにパケットを送信していると考えて
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などの前のプロトコルは、実際に新しいアドレスにデータを送信する前に、到達可能性チェックを追加することで行ってきました。他のプロトコルで使用されるソリューションは、明示的に4タプルIPAで識別MPTCP接続からのパケットを受け入れるかどうかを新しいアドレス（ターゲットTがIPTに座って）、ポートAに座ってホストを尋ねるためにソースSが含まれるであろう、IPSは、ポートS.これはターゲットTを有していることが確立された接続の一部ではないためには、Tは、要求を受け付けないとソースSは、このMPTCP接続用パケットを送信するために、IPTを使用しないであろう。通常、要求は、それが簡単に要求する偽の応答できないように攻撃者Aによって推測することができないnonceを含んでいます。 SCTPの場合には、（HEARTBEATに）64ビットのノンスを含むメッセージを送信します。
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トラバーサルなど）これを行うための他の理由がありますが、このようなアプローチはまた、到達可能性テストとして作用するであろうと、このセクションで説明フラッディング攻撃を防止するであろう。
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
MPTCP接続は、接続エンドポイント、IP1とIP2につき1つのアドレスだけを使用して、ノード1とノード2との間で確立されます。攻撃者は、その後、両方のケースでは、以来、ノード1のための追加アドレスの明示的または暗示的なアドレス管理の間に大きな違いはありませんとしてIPAを追加することにより、ハイジャック攻撃を開始します
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:
攻撃者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は、さらに、アプリケーションの観点から、これはサービス拒否（DoS）攻撃につながるノード2からすべてのデータを受信しませんので、これはすでに、マイナスの影響を持っています欠落したデータ。それはノード1とない攻撃者に到達するように、データの一部はまだ、IP1に配信されますので、しかし、接続の完全な乗っ取りを達成するのに十分ではありません。 MPTCP接続のすべてのデータを受信するために、攻撃者のためのためには、攻撃者が何らかの形で接続するための利用可能なアドレスのセットのIP1を削除する必要があります。暗黙的なアドレス管理の場合には、この操作は、または入力フィルタリングが適所にあると、攻撃者の位置か否かに応じて、攻撃者のために可能であってもなくてもよい送信元アドレスとしてIP1と終了パケットを送信暗示する可能性があります。明示的なアドレス管理が使用されている場合、攻撃者がIP1を含む削除アドレス制御パケットを送信します。 IP1が除去されると、ノード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に流れるセグメント：とすぐにIPAがMPTCP接続用のアドレスセットの一部としてノード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.
攻撃者AはMITMとしての地位を配置するMPTCPアドレスアジリティ機能を使用するノード1とノード2との間に確立された接続があります。そうするために、それはに関与する両方のノードに対して使用されるだけで、これは本質的に、このセクションで先に説明したのと同じ技術である両方のノード1とノード2上MPTCP接続のための追加のアドレスとしてIPアドレスIPAを追加します通信。主な違いは、この場合、攻撃者は単にそれを介して転送され、順番に通信のピアにデータを転送された通信の内容を盗聴することができるということです。結果は、攻撃者が通信の途中で自分自身を配置し、見過ごさトラフィックの一部を盗聴できるということです。攻撃者は適用ピアの本物のアドレスを削除することで、すべてのトラフィックを確認するために取得するために管理することができます方法については、同様の考察。
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.
ハイジャック攻撃を開始からオフパス攻撃を防止するための簡単な方法は、クッキーの使用により、アドレスを追加し、削除する制御メッセージにセキュリティを提供することです。アプローチのこのタイプでは、MPTCP接続に関係するピアは、接続の確立中に平文でやり取りされたクッキーに同意し、それはピアのいずれかのアドレスを追加または削除するすべての制御パケットに提示する必要があります。その結果、攻撃者は、前述のハイジャック攻撃のいずれかを起動するためにクッキーを知っている必要があるということです。これは、1つは、現在のTCPと同様のセキュリティでMPTCP接続結果を確保するためにクッキーベースのアプローチを検討することができるので、オフパス攻撃者は、もはや、ハイジャック攻撃を実行し、唯一のパス攻撃者がそうすることができるということを意味しません。それは近いですが、それは完全に真実ではありません。
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.
クッキーを通じて確保MPTCPのセキュリティと現在のTCPの主な違いは、タイムシフトの攻撃です。先に説明したように、タイムシフト攻撃は、攻撃者が期間中に道に沿って、その後、遠ざかるものの、攻撃者がいなくなって久しいされた後、攻撃の効果はまだ、残っているものです。クッキーの使用を介して固定MPTCPの場合、攻撃者は、クッキーが交換されるまでの経路に沿ってする必要があります。攻撃者はクッキーを学習した後は、それがパスから離れて移動することができ、まだ前のセクションで説明したハイジャック攻撃を開始することができます。
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ベースのソリューション：それは先に説明したように、一つの可能なアプローチは、既存の接続に新しいアドレスを追加し、すべてのMPTCP制御メッセージに平文で送信されたクッキーを使用することです。このタイプのソリューションの残留脅威はこれらの制御メッセージのいずれかを盗聴することができます任意の攻撃者はクッキーを学びますし、接続の存続期間中に任意の時点で新しいアドレスを追加できるようになることです。オリジナルのクッキーは、攻撃者によって使用されているので、エンドポイントが攻撃を検出しないであろう。まとめると、攻撃のこの種の脆弱性ウィンドウは、すべてのフローの確立交換を含み、それは、エンドポイントでは検出できないです。
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
O共有秘密は平文でやり取り：クッキーベースのアプローチよりも安全な代替オプションは、最初のサブフローの設立時に平文で鍵を交換して、キー付きハッシュを使用して、次のサブフローを検証することです
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.
共有鍵を用いてメッセージ認証コード（HMAC）署名。このソリューションは、最初のサブフローの確立のためのメッセージ交換を盗聴攻撃に対して脆弱になり、攻撃者が任意の他のメッセージを盗聴を通してそれを学ぶことができないので、その後、共有キーは、任意のより送信されていません。残念ながら、このアプローチは、鍵付きHMAC署名を含むにもかかわらず（以下分析を参照）のNATと互換性があるために、この署名が追加されている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によって書き換えられたアドレスを受け入れる必要があります。最も直接的な帰結は、彼らが自分のアドレスを変更するNATのを可能にしなければならないため、暗黙的なモードでアドレスを追加MPTCPメッセージが（つまり、新しいサブフローのSYN）は、整合性の攻撃から保護することができないということです。これは、サブフロー設立交換に使用されるアドレスを変更する攻撃者を防ぐために、完全性保護を提供することに依存しているであろう任意のソリューションを除外する。これは代替クリエイティブなメカニズムは、接続に新しいアドレスを追加する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が割り当てられたアドレスとポートを学び、安全な中で、その情報を伝えるために、このようなNATのセッショントラバーサルユーティリティ（STUN）などの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.
アラン・フォード - Rokeマナーリサーチ株式会社
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.
ロルフ冬、ランドール・スチュワート、アンドリュー・マクドナルド、マイケルTuexen、マイケル・シャーフ、ティム・シェパード、西田佳史、ラースEggertの、フィル・Eardley、ヤリArkko、デヴィッド・ハリントン、ダンRomascanu、およびアレクセイ・メルニコフはこのドキュメントの以前のバージョンを検討し、コメントの提供しますそれを改善。
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.
マルセロBagnuloの一部トリロジー、その第七次フレームワーク計画の下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されます。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、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.、オーラ、T.、モンテネグロ、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.李、RFC 4218、2005年10月の "IPv6マルチホーミングソリューションに関連脅威"。
[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]スチュワート、R.、Tuexen、M.、およびG.カマリロ、RFC 5062、2007年9月 "ストリーム制御伝送プロトコル（SCTP）と現在の対策反し見つかりセキュリティ攻撃"。
[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]ジョンソン、D.、パーキンス、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]スチュワート、R.、 "ストリーム制御伝送プロトコル"、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-同報]フォード、A.、Raiciu、C.、およびM.ハンドリー、 "複数のアドレスを持つマルチパス操作のためのTCP拡張機能"、進歩、2010年10月の作業。
Author's Address
著者のアドレス
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
マドリードのマルセロBagnuloチャールズIII大学のAv。大学30レガネス、マドリード28911スペイン
Phone: 34 91 6248814 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es
電話：34 91 6248814 Eメール：marcelo@it.uc3m.es URI：http://www.it.uc3m.es