Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6181 UC3M
Category: Informational March 2011
ISSN: 2070-1721
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.
多路径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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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[RFC0793]提出的扩展，以便给定TCP连接的端点可以使用多条路径来交换数据。这种扩展允许使用不同的源-目的地址对交换段，从而在大量场景中使用多条路径。通过这些扩展，可以实现一定程度的多宿和移动支持。但是，对每个端点的多个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。本质上，需要的是让发送方能够指定某种形式的路径选择器，从而使不同的通信段通过不同的路径转发。这种路径选择器有多种选择，包括使用不同的下一个跃点、使用到不同出口点的隧道等等。本说明中包含的分析范围仅限于特定方法，即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（每个端点只有一个地址可供每个连接使用）相比，多地址支持导致的额外漏洞。对整套威胁的全面分析显然超出了范围。此分析的目标是帮助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
分析的重点是不在路径上的攻击者，至少不在整个连接期间。在当前的单路径TCP中，路径上的攻击者可以启动
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.
大量攻击，包括窃听、连接劫持中间人（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:
在移动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情况下，一个连接处于危险之中。如果在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中，有一个受信任的第三方，称为Home Agent，可以帮助解决一些安全问题，如下一个项目中所述。
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中，当其中一个地址对不再可用时，提供通信弹性是一个明确的目标，因此不可能利用原始地址对始终工作。
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设计的，MPTCP的明确目标是同时支持IPv6和IPv4。一些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层协议，因此涉及目标地址的所有通信都处于危险之中；在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仅使用IPv6地址作为标识符，并利用其某些属性来提供安全性，例如依赖CGA或基于哈希的地址（HBA）[RFC5535]，这在必须支持IPv4地址的MPTCP情况下是不可能的。
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
流控制传输协议（SCTP）[RFC4960]是一种传输协议，每个端点支持多个地址，其安全性与MPTCP非常接近。安全分析，识别一组攻击并提出
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.
溶液在[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
用于建立连接的地址确实具有特殊的作用，因为这是上层用作标识符的地址。在SYN数据包中用作目标地址的地址是应用程序用于识别对等方的地址，该地址已通过DNS（带或不带DNS安全性（DNSSEC）验证）获得，或通过引用传递，或由用户手动引入。因此，发起者确实对其正在与该特定地址建立通信这一事实具有一定程度的信任。如果由于MPTCP，数据包最终被传送到另一个地址，则发起方对该地址的信任将被欺骗。在任何情况下，采用MPTCP都需要对传统的TCP信任模型稍作改进，因为发起方额外信任对等方，以提供其将信任的其他地址
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.
达到与原始对相同的程度。不能以这种方式信任对等方的应用程序或实现不应使用多条路径。
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.
对于某些类型的攻击，这两种模式具有不同的安全属性。显式模式似乎更容易被滥用。隐式模式可能受益于各种形式的入口过滤安全性，这将降低攻击者向正在进行的连接添加任意地址的可能性。然而，入口过滤部署远不是通用的，将其作为保护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 |
+------+
+--------+ (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的攻击者组成。可以产生大量流量的服务器（如流式服务器），称为源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
在此攻击的步骤1中，攻击者A与流量服务器S的源建立MPTCP连接，并开始下载大量流量。初始连接仅涉及每个端点的一个IP地址，即IPA和IPS。一旦下载成功，在攻击的步骤2中，攻击者会添加一个IPT作为通信的可用地址之一。如何添加附加地址取决于MPTCP地址管理模式。在显式地址管理中，攻击者A只需要发送一个传递地址IPT的信令包。在隐式模式下，攻击者A需要发送一个以IPT作为源地址的数据包。根据是否部署了入口过滤以及攻击者的位置，攻击者可能发送或不发送此类数据包。在此阶段，MPTCP连接仍然有一个源地址，即IPS，但有两个攻击者地址a、IPA和IPT。攻击者现在试图让源S将正在进行的下载流量发送到目标IP地址，即IPT。攻击者可以通过假装IPA和IPT之间的路径拥挤，但IPS和IPT之间的路径不拥挤来做到这一点。为此，它需要发送通过IPS和IPT之间路径的数据的确认，而不是发送发送到IPA的数据的确认。这方面的细节将取决于如何确认通过不同路径发送的数据。一种可能性是，使用给定地址对发送的数据的ack应该包含
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.
相同的地址对。如果是这样，攻击者将需要使用包含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，必须处理这种类型的攻击，在实际将数据发送到新地址之前添加可达性检查。其他协议中使用的解决方案将包括源S明确询问位于新地址的主机（位于IPT中的目标T）是否愿意接受由4元组IPA、端口A、IPS、端口S标识的MPTCP连接的数据包。因为这不是目标T所拥有的已建立连接的一部分，T将不接受请求，并且源S将不使用IPT为此MPTCP连接发送数据包。通常，请求还包含一个攻击者无法猜测的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.
进行此可达性测试的一种可能方法是为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 |
+--------+
+------+ +------+
| 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
在节点1和节点2之间建立MPTCP连接。每个端点只使用一个地址，即IP1和IP2。然后，攻击者通过添加IPA作为节点1的附加地址来发起劫持攻击。显式和隐式地址管理之间没有太大区别，因为在这两种情况下
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:
攻击者可以轻松发送添加地址IPA的控制数据包，作为控制数据或控制数据包的源地址。为了能够劫持连接，攻击者需要知道标识连接的4元组，包括地址对和端口对。似乎可以合理地假设攻击者很容易知道源和目标IP地址以及服务器端的端口。了解客户端（即连接的发起方）的端口可能更具挑战性。攻击者需要猜测端口是什么，或者通过截获数据包来了解端口。假设攻击者可以收集4元组并发出消息，将IPA添加到MPTCP连接可用的地址，则攻击者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被删除，节点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的段：一旦节点2接受IPA作为MPTCP连接地址集的一部分，攻击者就可以使用IPA发送数据包，节点2将这些数据包视为MPTCP连接的一部分。这意味着攻击者将能够将数据注入MPTCP连接，因此从这个角度来看，攻击者劫持了部分传出流量。然而，节点1仍然能够发送将由节点2作为MPTCP连接的一部分接收的通信量。这意味着将有两个数据源，即节点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 |
+--------+
+------+ +------+
| 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需要在为任何对等方添加或移除地址的每个控制分组中呈现。结果是，攻击者需要知道cookie，才能发起前面描述的任何劫持攻击。这意味着非路径攻击者不再能够执行劫持攻击，并且只有在路径攻击者能够做到这一点，所以可以考虑基于cookie的方法来安全地保护MPTCP连接结果与当前TCP类似的安全性。虽然这很接近，但并不完全正确。
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的解决方案：如前所述，一种可能的方法是在每个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
o 以明文交换的共享秘密：比基于cookie的方法更安全的另一种选择是，在建立第一个子流期间以明文交换密钥，然后使用密钥散列验证以下子流
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）签名。此解决方案容易受到攻击者的攻击，攻击者通过嗅探消息交换来建立第一个子流，但在此之后，共享密钥将不再传输，因此攻击者无法通过嗅探任何其他消息来学习共享密钥。不幸的是，为了与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
为了被广泛采用，MPTCP必须通过NAT工作。从安全角度来看，NAT是一种有趣的设备。就MPTCP而言，它们本质上表现为MiTM攻击者。MPTCP的安全目标是防止任何攻击者将其地址作为给定MPTCP连接的有效地址插入。但这正是NAT所做的：它修改地址。所以，若MPTCP要通过NAT工作，MPTCP必须接受NAT重写的地址作为给定会话的有效地址。最直接的推论是，以隐式模式添加地址的MPTCP消息（即，新子流的SYN）不能受到完整性攻击的保护，因为它们必须允许NAT更改其地址。这排除了
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信令不受完整性攻击，该信令会向连接添加新地址。在这一点上，这样一种创造性的方法究竟会是什么样子还远未可知。
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工作组的不同方面进行评估后，得出以下结论：
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应在向正在进行的通信中添加新地址之前，使用随机nonce（例如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.
艾伦·福特-罗克庄园研究有限公司。
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.
Rolf Winter、Randall Stewart、Andrew McDonald、Michael Tuexen、Michael Scharf、Tim Shepard、Yoshifumi Nishida、Lars Eggert、Phil Eardley、Jari Arkko、David Harrington、Dan Romascanu和Alexey Melnikov审查了本文件的早期版本，并提供了改进意见。
Mark Handley pointed out the problem with NATs and integrity protection of MPTCP signaling.
Mark Handley指出了NAT和MPTCP信令完整性保护的问题。
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnulo的部分资金来自Trilogy，这是一个由欧盟委员会第七个框架计划支持的研究项目。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准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.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.translate error, please retry
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年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）”，RFC5352009年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 37752004年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 55332009年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年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
马德里卡洛斯三世大学。西班牙马德里勒加内斯30大学28911
Phone: 34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Phone: 34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es