Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 7430 UC3M
Category: Informational C. Paasch
ISSN: 2070-1721 UCLouvain
F. Gont
SI6 Networks / UTN-FRH
O. Bonaventure
UCLouvain
C. Raiciu
UPB
July 2015
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 7430 UC3M
Category: Informational C. Paasch
ISSN: 2070-1721 UCLouvain
F. Gont
SI6 Networks / UTN-FRH
O. Bonaventure
UCLouvain
C. Raiciu
UPB
July 2015
Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)
分析多路径TCP（MPTCP）的残余威胁和可能的修复方法
Abstract
摘要
This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.
本文档分析了多路径TCP（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/rfc7430.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7430.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. ADD_ADDR Attack . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Possible Security Enhancements to Prevent This Attack . . 10
3. DoS Attack on MP_JOIN . . . . . . . . . . . . . . . . . . . . 11
3.1. Possible Security Enhancements to Prevent This Attack . . 12
4. SYN Flooding Amplification . . . . . . . . . . . . . . . . . 12
4.1. Possible Security Enhancements to Prevent This Attack . . 13
5. Eavesdropper in the Initial Handshake . . . . . . . . . . . . 13
5.1. Possible Security Enhancements to Prevent This Attack . . 14
6. SYN/JOIN Attack . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Possible Security Enhancements to Prevent This Attack . . 14
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. MPTCP Security Improvements for a Standards Track
Specification . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Security Enhancements for MPTCP . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ADD_ADDR Attack . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Possible Security Enhancements to Prevent This Attack . . 10
3. DoS Attack on MP_JOIN . . . . . . . . . . . . . . . . . . . . 11
3.1. Possible Security Enhancements to Prevent This Attack . . 12
4. SYN Flooding Amplification . . . . . . . . . . . . . . . . . 12
4.1. Possible Security Enhancements to Prevent This Attack . . 13
5. Eavesdropper in the Initial Handshake . . . . . . . . . . . . 13
5.1. Possible Security Enhancements to Prevent This Attack . . 14
6. SYN/JOIN Attack . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Possible Security Enhancements to Prevent This Attack . . 14
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. MPTCP Security Improvements for a Standards Track
Specification . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Security Enhancements for MPTCP . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
This document provides a complement to the threat analysis for Multipath TCP (MPTCP) [RFC6824] documented in RFC 6181 [RFC6181]. RFC 6181 provided a threat analysis for the general solution space of extending TCP to operate with multiple IP addresses per connection. Its main goal was to leverage previous experience acquired during the design of other multi-address protocols, notably Shim6 [RFC5533], the Stream Control Transmission Protocol (SCTP) [RFC4960], and Mobile IPv6 (MIP6) [RFC6275] for designing MPTCP. Thus, RFC 6181 was produced before the actual MPTCP specification (RFC 6824) was completed and documented a set of recommendations that were considered during the production of that specification.
本文档补充了RFC 6181[RFC6181]中记录的多路径TCP（MPTCP）[RFC6824]威胁分析。RFC6181为扩展TCP以在每个连接上使用多个IP地址进行操作的通用解决方案空间提供了威胁分析。其主要目标是利用以前在设计其他多地址协议时获得的经验，特别是在设计MPTCP时使用的Shim6[RFC5533]、流控制传输协议（SCTP）[RFC4960]和移动IPv6（MIP6）[RFC6275]。因此，RFC 6181是在实际MPTCP规范（RFC 6824）完成之前产生的，并记录了在该规范产生过程中考虑的一组建议。
This document complements RFC 6181 with a vulnerability analysis of the mechanisms specified in RFC 6824. The motivation for this analysis is to identify possible security issues with MPTCP as currently specified and propose security enhancements to address these identified security issues.
本文件对RFC 6181进行了补充，对RFC 6824中规定的机制进行了漏洞分析。此分析的目的是确定MPTCP可能存在的安全问题（如当前所述），并提出安全增强措施以解决这些已确定的安全问题。
The goal of the security mechanisms defined in RFC 6824 was to make MPTCP no worse than currently available single-path TCP. We believe that this goal is still valid, so we will perform our analysis on the same grounds. This document describes all the threats identified that are specific to MPTCP (as defined in RFC 6824) that are not possible with single-path TCP. This means that threats that are common to TCP and MPTCP are not covered in this document.
RFC6824中定义的安全机制的目标是使MPTCP不比当前可用的单路径TCP差。我们相信这一目标仍然有效，因此我们将根据同样的理由进行分析。本文档描述了针对MPTCP（定义见RFC 6824）识别的所有威胁，这些威胁在单路径TCP中是不可能的。这意味着本文档不包括TCP和MPTCP常见的威胁。
For each attack considered in this document, we identify the type of attacker. We can classify the attackers based on their location as follows:
对于本文档中考虑的每个攻击，我们都会确定攻击者的类型。我们可以根据攻击者的位置对其进行如下分类：
o Off-path attacker. This is an attacker that does not need to be located in any of the paths of the MPTCP session at any point in time during the lifetime of the MPTCP session. This means that the off-path attacker cannot eavesdrop any of the packets of the MPTCP session.
o 非路径攻击者。这是一个攻击者，在MPTCP会话的生存期内的任何时间点都不需要位于MPTCP会话的任何路径中。这意味着非路径攻击者无法窃听MPTCP会话的任何数据包。
o Partial-time on-path attacker. This is an attacker that needs to be in at least one of the paths during part of the lifetime of the MPTCP session (but not the entire lifetime). The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o 路径攻击者的部分时间。这是一个攻击者，在MPTCP会话的部分生存期（而不是整个生存期）内，需要至少位于其中一条路径中。攻击者可以在初始子流和/或其他子流的前进和/或后退方向。攻击者的具体需求将在攻击描述中明确说明。
o On-path attacker. This attacker needs to be on at least one of the paths during the whole duration of the MPTCP session. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o 路径上的攻击者。在MPTCP会话的整个过程中，该攻击者需要至少位于其中一条路径上。攻击者可以在初始子流和/或其他子流的前进和/或后退方向。攻击者的具体需求将在攻击描述中明确说明。
We can also classify the attackers based on their actions as follows:
我们还可以根据攻击者的行为对其进行如下分类：
o Eavesdropper. The attacker is able to capture some of the packets of the MPTCP session to perform the attack, but it is not capable of changing, discarding, or delaying any packet of the MPTCP session. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o 窃听者。攻击者能够捕获MPTCP会话的某些数据包以执行攻击，但无法更改、丢弃或延迟MPTCP会话的任何数据包。攻击者可以在初始子流和/或其他子流的前进和/或后退方向。攻击者的具体需求将在攻击描述中明确说明。
o Active attacker. The attacker is able to change, discard, or delay some of the packets of the MPTCP session. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o 主动攻击者。攻击者可以更改、丢弃或延迟MPTCP会话的某些数据包。攻击者可以在初始子流和/或其他子流的前进和/或后退方向。攻击者的具体需求将在攻击描述中明确说明。
In this document, we consider the following possible combinations of attackers:
在本文中，我们考虑以下可能的攻击者组合：
o an on-path eavesdropper
o 路上的窃听者
o an on-path active attacker
o 路径上的主动攻击者
o an off-path active attacker
o 非路径主动攻击者
o a partial-time on-path eavesdropper
o 部分时间路径窃听器
o a partial-time on-path active attacker
o 部分时间在路径上活动的攻击者
In the rest of the document, we describe different attacks that are possible against the MPTCP protocol specified in RFC 6824 and propose possible security enhancements to address them.
在本文档的其余部分中，我们描述了可能针对RFC 6824中指定的MPTCP协议的不同攻击，并提出了可能的安全增强措施来解决这些攻击。
Summary of the attack:
攻击摘要：
Type of attack: MPTCP session hijack enabling a man-in-the-middle (MitM) attack
攻击类型：MPTCP会话劫持启用中间人（MitM）攻击
Type of attacker: off-path active attacker
攻击者类型：非路径活动攻击者
Description:
说明：
In this attack, the attacker uses the ADD_ADDR option defined in RFC 6824 to hijack an ongoing MPTCP session and enable himself to perform a man-in-the-middle attack on the MPTCP session.
在此攻击中，攻击者使用RFC 6824中定义的ADD_ADDR选项劫持正在进行的MPTCP会话，并使自己能够对MPTCP会话执行中间人攻击。
Consider the following scenario. Host A with address IPA has one MPTCP session with Host B with address IPB. The MPTCP subflow between IPA and IPB is using port PA on Host A and port PB on Host B. The tokens for the MPTCP session are TA and TB for Host A and Host B, respectively. Host C is the attacker. It owns address IPC. The attack is executed as follows:
考虑下面的场景。地址为IPA的主机A与地址为IPB的主机B有一个MPTCP会话。IPA和IPB之间的MPTCP子流使用主机A上的端口PA和主机B上的端口PB。MPTCP会话的令牌分别是主机A和主机B的TA和TB。主机C是攻击者。它拥有IPC地址。攻击按如下方式执行：
1. Host C sends a forged packet with source address IPA, destination address IPB, source port PA, and destination port PB. The packet has the ACK flag set. The TCP sequence number for the segment is i, and the ACK sequence number is j. We will assume all these are valid; later, we discuss what the attacker needs to figure them out. The packet contains the ADD_ADDR option. The ADD_ADDR option announces IPC as an alternative address for the connection. It also contains an 8-bit address identifier that does not provide any strong security benefit.
1. 主机C发送带有源地址IPA、目标地址IPB、源端口PA和目标端口PB的伪造数据包。该数据包设置了ACK标志。段的TCP序列号为i，ACK序列号为j。我们将假定所有这些都是有效的；稍后，我们将讨论攻击者需要了解什么。数据包包含ADD_ADDR选项。ADD_ADDR选项宣布IPC为连接的替代地址。它还包含一个8位地址标识符，不提供任何强大的安全优势。
2. Host B receives the ADD_ADDR message and replies by sending a TCP SYN packet.
2. 主机B接收ADD_ADDR消息，并通过发送TCP SYN数据包进行回复。
Note: The MPTCP specification [RFC6824] states that the host receiving the ADD_ADDR option may initiate a new subflow. If the host is configured so that it does not initiate a new subflow, the attack will not succeed. For example, on the current Linux implementation, the server does not create subflows. Only the client does so.
注意：MPTCP规范[RFC6824]规定，接收ADD_ADDR选项的主机可以启动新的子流。如果主机配置为不启动新子流，则攻击将不会成功。例如，在当前的Linux实现上，服务器不创建子流。只有客户机这样做。
The source address for the packet is IPB; the destination address for the packet is IPC; the source port is PB'; and the destination port is PA' (it is not required that PA=PA' nor that PB=PB'). The sequence number for this packet is the new initial sequence number for this subflow. The ACK sequence number is not relevant as the ACK flag is not set. The packet carries an MP_JOIN option and the token TA. It also carries a random nonce generated by Host B called RB.
数据包的源地址是IPB；数据包的目的地址为IPC；源端口为PB'；并且目标端口是PA'（不要求PA=PA'或PB=PB'）。此数据包的序列号是此子流的新初始序列号。由于未设置ACK标志，ACK序列号不相关。数据包携带一个MP_连接选项和令牌TA。它还携带由主机B生成的名为RB的随机nonce。
3. Host C receives the SYN+MP_JOIN packet from Host B and alters it in the following way. It changes the source address to IPC and the destination address to IPA. It sends the modified packet to Host A, impersonating Host B.
3. 主机C从主机B接收SYN+MP_JOIN数据包，并按以下方式对其进行更改。它将源地址更改为IPC，目标地址更改为IPA。它将修改后的数据包发送到主机A，模拟主机B。
4. Host A receives the SYN+MP_JOIN message and replies with a SYN/ACK+MP_JOIN message. The packet has source address IPA and destination address IPC, as well as all the other needed parameters. In particular, Host A computes a valid Hashed Message Authentication Code (HMAC) and places it in the MP_JOIN option.
4. 主机A接收SYN+MP_加入消息，并用SYN/ACK+MP_加入消息进行回复。数据包具有源地址IPA和目标地址IPC，以及所有其他需要的参数。特别是，主机A计算一个有效的哈希消息身份验证码（HMAC），并将其放置在MP_JOIN选项中。
5. Host C receives the SYN/ACK+MP_JOIN message and changes the source address to IPC and the destination address to IPB. It sends the modified packet to IPB, impersonating Host A.
5. 主机C接收SYN/ACK+MP_JOIN消息，并将源地址更改为IPC，将目标地址更改为IPB。它将修改后的数据包发送到IPB，模拟主机A。
6. Host B receives the SYN/ACK+MP_JOIN message. Host B verifies the HMAC of the MP_JOIN option and confirms its validity. It replies with an ACK+MP_JOIN packet. The packet has source address IPB and destination address IPC, as well as all the other needed parameters. The returned MP_JOIN option contains a valid HMAC computed by Host B.
6. 主机B接收SYN/ACK+MP\U JOIN消息。主机B验证MP_JOIN选项的HMAC并确认其有效性。它用ACK+MP_连接数据包进行回复。数据包具有源地址IPB和目标地址IPC，以及所有其他需要的参数。返回的MP_JOIN选项包含由主机B计算的有效HMAC。
7. Host C receives the ACK+MP_JOIN message from B and alters it in the following way. It changes the source address to IPC and the destination address to IPA. It sends the modified packet to Host A, impersonating Host B.
7. 主机C从B接收ACK+MP_JOIN消息，并按以下方式对其进行更改。它将源地址更改为IPC，目标地址更改为IPA。它将修改后的数据包发送到主机A，模拟主机B。
8. Host A receives the ACK+MP_JOIN message and creates the new subflow. At this point, the attacker has managed to place itself as a MitM for one subflow for the existing MPTCP session. It should be noted that the subflow between addresses IPA and IPB that does not flow through the attacker still exists, so the attacker has not completely intercepted all the packets in the communication (yet). If the attacker wishes to completely intercept the MPTCP session, it can do the following additional step.
8. 主机A接收ACK+MP_JOIN消息并创建新的子流。此时，攻击者已成功将自己作为现有MPTCP会话的一个子流的MitM。应该注意的是，地址IPA和IPB之间的子流仍然存在，因此攻击者尚未完全截获通信中的所有数据包。如果攻击者希望完全拦截MPTCP会话，则可以执行以下附加步骤。
9. Host C sends two TCP RST messages. One TCP RST packet is sent to Host B, with source address IPA, destination address IPB, and source and destination ports PA and PB, respectively. The other TCP RST message is sent to Host A, with source address IPB, destination address IPA, and source and destination ports PB and PA, respectively. Both RST messages must contain a valid sequence number. Note that figuring the sequence numbers to be used here for subflow A is the same difficulty as being able to send the initial ADD_ADDR option with valid sequence number and ACK value. If there are more subflows, then the attacker needs to find the sequence number and ACK for each subflow. At this point, the attacker has managed to fully hijack the MPTCP session.
9. 主机C发送两条TCP RST消息。一个TCP RST数据包被发送到主机B，分别具有源地址IPA、目标地址IPB以及源和目标端口PA和PB。另一条TCP RST消息被发送到主机A，分别具有源地址IPB、目标地址IPA以及源和目标端口PB和PA。两条RST消息必须包含有效的序列号。请注意，计算此处用于子流A的序列号与使用有效序列号和ACK值发送初始ADD_ADDR选项的难度相同。如果有更多子流，则攻击者需要查找每个子流的序列号和ACK。此时，攻击者已成功完全劫持MPTCP会话。
Information required by the attacker to perform the described attack:
攻击者执行所述攻击所需的信息：
In order to perform this attack the attacker needs to guess or know the following pieces of information. The attacker needs this information for one of the subflows belonging to the MPTCP session.
为了执行此攻击，攻击者需要猜测或知道以下信息。对于属于MPTCP会话的子流之一，攻击者需要此信息。
o the four-tuple {Client-side IP Address, Client-side Port, Server-side Address, Server-side Port} that identifies the target TCP connection
o 标识目标TCP连接的四个元组{客户端IP地址、客户端端口、服务器端地址、服务器端端口}
o a valid sequence number for the subflow
o 子流的有效序列号
o a valid ACK sequence number for the subflow
o 子流的有效ACK序列号
o a valid address identifier for IPC
o IPC的有效地址标识符
TCP connections are uniquely identified by the four-tuple {Source Address, Source Port, Destination Address, Destination Port}. Thus, in order to attack a TCP connection, an attacker needs to know or be able to guess each of the values in that four-tuple. Assuming the two peers of the target TCP connection are known, the Source Address and the Destination Address can be assumed to be known.
TCP连接由四个元组{源地址、源端口、目标地址、目标端口}唯一标识。因此，为了攻击TCP连接，攻击者需要知道或能够猜测这四个元组中的每个值。假设目标TCP连接的两个对等方是已知的，则可以假设源地址和目标地址是已知的。
Note: In order to be able to successfully perform this attack, the attacker needs to be able to send packets with a forged source address. This means that the attacker cannot be located in a network where techniques like ingress filtering [RFC2827] or source address validation [RFC7039] are deployed. However, ingress filtering is not as widely implemented as one would expect and hence cannot be relied upon as a mitigation for this kind of attack.
注意：为了能够成功执行此攻击，攻击者需要能够发送具有伪造源地址的数据包。这意味着攻击者无法定位在部署了入口过滤[RFC2827]或源地址验证[RFC7039]等技术的网络中。然而，入口过滤并不像人们预期的那样广泛实施，因此不能作为此类攻击的缓解措施。
Assuming the attacker knows the application protocol for which the TCP connection is being employed, the server-side port can also be assumed to be known. Finally, the client-side port will generally not be known and will need to be guessed by the attacker. The chances of an attacker guessing the client-side port will depend on the ephemeral port range employed by the client and whether or not the client implements port randomization [RFC6056].
假设攻击者知道使用TCP连接的应用程序协议，也可以假设服务器端端口是已知的。最后，客户端端口通常是未知的，需要攻击者猜测。攻击者猜测客户端端口的可能性取决于客户端使用的临时端口范围以及客户端是否实现端口随机化[RFC6056]。
Assuming TCP sequence number randomization is in place (see e.g., [RFC6528]), an attacker would have to blindly guess a valid TCP sequence number. That is,
假设TCP序列号随机化已到位（例如，请参见[RFC6528]），攻击者将不得不盲目猜测有效的TCP序列号。就是，
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =<
SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =<
SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
As a result, the chances of an attacker succeeding will depend on the TCP receive window size at the target TCP peer.
因此，攻击者成功的机会将取决于目标TCP对等方的TCP接收窗口大小。
Note: Automatic TCP buffer tuning mechanisms have become common for popular TCP implementations; hence, very large TCP window sizes of values up to 2 MB could end up being employed by such TCP implementations.
注意：对于流行的TCP实现，自动TCP缓冲区调优机制已经变得很常见；因此，值高达2MB的超大TCP窗口最终可能会被此类TCP实现所采用。
According to [RFC793], the acknowledgement number is considered valid as long as it does not acknowledge the receipt of data that has not yet been sent. That is, the following expression must be true:
根据[RFC793]，只要确认号不确认尚未发送的数据的接收，则确认号视为有效。也就是说，以下表达式必须为真：
SEG.ACK <= SND.NXT
SEG.ACK<=SND.NXT
However, for implementations that support [RFC5961], the following (stricter) validation check is enforced:
但是，对于支持[RFC5961]的实现，将强制执行以下（更严格的）验证检查：
SND.UNA - MAX.SND.WND <= SEG.ACK <= SND.NXT
SND.UNA - MAX.SND.WND <= SEG.ACK <= SND.NXT
Finally, in order for the address identifier to be valid, the only requirement is that it needs to be different from the ones already being used by Host A in that MPTCP session, so a random identifier is likely to work.
最后，为了使地址标识符有效，唯一的要求是它需要与主机A在该MPTCP会话中已经使用的标识符不同，因此随机标识符可能会起作用。
Given that a large number of factors affect the chances of an attacker successfully performing the aforementioned off-path attacks, we provide two general expressions for the expected number of packets the attacker needs to send to succeed in the attack: one for MPTCP implementations that support [RFC5961] and another for MPTCP implementations that do not.
鉴于大量因素影响攻击者成功执行上述非路径攻击的机会，我们提供了两个通用表达式，说明攻击者需要发送的预期数据包数量，以成功进行攻击：一个用于支持[RFC5961]的MPTCP实现另一个用于不需要的MPTCP实现。
Implementations that do not support RFC 5961:
不支持RFC 5961的实现：
Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS
Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS
Where the new parameters are:
其中新参数为：
Packets: Maximum number of packets required to successfully perform an off-path (blind) attack.
数据包：成功执行非路径（盲）攻击所需的最大数据包数。
RCV_WND: TCP receive window size (RCV.WND) at the target node.
RCV_WND：目标节点上的TCP接收窗口大小（RCV.WND）。
EPH_PORT_SIZE: Number of ports comprising the ephemeral port range at the "client" system.
EPH_PORT_SIZE：在“客户端”系统中包含临时端口范围的端口数。
MSS: Maximum Segment Size, assuming the attacker will send full segments to maximize the chances of getting a hit.
MSS：最大段大小，假设攻击者将发送完整段以最大限度地提高命中率。
Notes: The value "2^32" represents the size of the TCP sequence number space.
注意：值“2^32”表示TCP序列号空间的大小。
The value "2" accounts for two different ACK numbers (separated by 2^31) that should be employed to make sure the ACK number is valid.
值“2”表示两个不同的ACK编号（由2^31分隔），应使用这两个编号来确保ACK编号有效。
The following table contains some sample results for the number of required packets, based on different values of RCV_WND and EPH_PORT_SIZE for an MSS of 1500 bytes.
下表包含根据1500字节MSS的RCV_WND和EPH_PORT_SIZE的不同值得出的所需数据包数量的一些示例结果。
+-------------+---------+---------+--------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+---------+---------+--------+---------+
| 4000 | 699050 | 87381 | 43690 | 5461 |
+-------------+---------+---------+--------+---------+
| 10000 | 1747626 | 218453 | 109226 | 13653 |
+-------------+---------+---------+--------+---------+
| 50000 | 8738133 | 1092266 | 546133 | 68266 |
+-------------+---------+---------+--------+---------+
+-------------+---------+---------+--------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+---------+---------+--------+---------+
| 4000 | 699050 | 87381 | 43690 | 5461 |
+-------------+---------+---------+--------+---------+
| 10000 | 1747626 | 218453 | 109226 | 13653 |
+-------------+---------+---------+--------+---------+
| 50000 | 8738133 | 1092266 | 546133 | 68266 |
+-------------+---------+---------+--------+---------+
Table 1: Maximum Number of Packets for Successful Attack
表1：成功攻击的最大数据包数
Implementations that do support RFC 5961:
支持RFC 5961的实现：
Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) *
EPH_PORT_SIZE/2 * 1/MSS
Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) *
EPH_PORT_SIZE/2 * 1/MSS
Where:
哪里：
Packets: Maximum number of packets required to successfully perform an off-path (blind) attack.
数据包：成功执行非路径（盲）攻击所需的最大数据包数。
RCV_WND: TCP receive window size (RCV.WND) at the target MPTCP endpoint.
RCV_WND：目标MPTCP端点处的TCP接收窗口大小（RCV.WND）。
SND_MAX_WND: Maximum TCP send window size ever employed by the target MPTCP endpoint (MAX.SND.WND).
SND_MAX_WND：目标MPTCP端点使用的最大TCP发送窗口大小（MAX.SND.WND）。
EPH_PORT_SIZE: Number of ports comprising the ephemeral port range at the "client" system.
EPH_PORT_SIZE：在“客户端”系统中包含临时端口范围的端口数。
Notes: The value "2^32" represents the size of the TCP sequence number space.
注意：值“2^32”表示TCP序列号空间的大小。
The parameter "MAX.SND.WND" is specified in [RFC5961].
[RFC5961]中规定了参数“MAX.SND.WND”。
The value "2 * SND_MAX_WND" results from the expression "SND.NXT - SND.UNA - MAX.SND.WND", assuming that, for connections that perform bulk data transfers, "SND.NXT - SND.UNA == MAX.SND.WND". If an attacker targets a TCP endpoint that is not actively transferring data, "2 * SND_MAX_WND" would become "SND_MAX_WND" (and hence a successful attack would typically require more packets).
值“2*SND_MAX_WND”来自表达式“SND.NXT-SND.UNA-MAX.SND.WND”，假设对于执行批量数据传输的连接，“SND.NXT-SND.UNA==MAX.SND.WND”。如果攻击者以未主动传输数据的TCP端点为目标，“2*SND_MAX_WND”将变为“SND_MAX_WND”（因此成功的攻击通常需要更多数据包）。
The following table contains some sample results for the number of required packets, based on different values of RCV_WND, SND_MAX_WND, and EPH_PORT_SIZE. For these implementations, only a limited number of sample results are provided (as an indication of how [RFC5961] increases the difficulty of performing these attacks).
下表包含基于RCV_WND、SND_MAX_WND和EPH_PORT_SIZE的不同值的所需数据包数量的一些示例结果。对于这些实现，只提供有限数量的示例结果（作为[RFC5961]如何增加执行这些攻击的难度的指示）。
+-------------+-------------+-----------+-----------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+-------------+-----------+-----------+---------+
| 4000 | 45812984490 | 715827882 | 178956970 | 2796202 |
+-------------+-------------+-----------+-----------+---------+
+-------------+-------------+-----------+-----------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+-------------+-----------+-----------+---------+
| 4000 | 45812984490 | 715827882 | 178956970 | 2796202 |
+-------------+-------------+-----------+-----------+---------+
Table 2: Maximum Number of Packets for Successful Attack
表2：成功攻击的最大数据包数
Note: In the aforementioned table, all values are computed with RCV_WND equal to SND_MAX_WND.
注：在上述表格中，所有值均使用等于SND_MAX_WND的RCV_WND计算。
1. To include the token of the connection in the ADD_ADDR option. This would make it harder for the attacker to launch the attack, since the attacker needs to either eavesdrop the token (so this can no longer be a blind attack) or to guess it, but a random 32-bit number is not easy to guess. However, this would imply that any eavesdropper that is able to see the token would be able
1. 在ADD_ADDR选项中包含连接的令牌。这将使攻击者更难发起攻击，因为攻击者需要窃听令牌（因此这不再是盲攻击）或猜测令牌，但随机32位数字不容易猜测。然而，这意味着任何能够看到令牌的窃听者都可以
to launch this attack. This solution then increases the vulnerability window against eavesdroppers from the initial 3-way handshake for the MPTCP session to any exchange of the ADD_ADDR messages.
发动这次攻击。然后，该解决方案增加了针对窃听者的漏洞窗口，从MPTCP会话的初始三方握手到任何ADD_ADDR消息交换。
2. To include the HMAC of the address contained in the ADD_ADDR option. The key used for the HMAC is the concatenation of the key of the receiver and the key of the sender (in the same way they are used for generating the HMAC of the MP_JOIN message). This makes it much more secure, since it requires the attacker to have both keys (either by eavesdropping it in the first exchange or by guessing it). Because this solution relies on the key used in the MPTCP session, the protection of this solution would increase if new key generation methods are defined for MPTCP (e.g., using Secure Socket Layer (SSL) keys as has been proposed).
2. 要包括ADD_ADDR选项中包含的地址的HMAC。HMAC使用的密钥是接收方的密钥和发送方的密钥的级联（与它们用于生成MP_JOIN消息的HMAC的方式相同）。这使得它更加安全，因为它要求攻击者同时拥有两个密钥（要么在第一次交换时窃听，要么猜测）。由于此解决方案依赖于MPTCP会话中使用的密钥，因此如果为MPTCP定义新的密钥生成方法（例如，使用已提出的安全套接字层（SSL）密钥），则此解决方案的保护将增加。
3. To include the destination address of the SYN packet in the HMAC of the MP_JOIN message. As the attacker requires changing the destination address to perform the described attack, protecting it would prevent the attack. It wouldn't allow hosts behind NATs to be reached by an address in the ADD_ADDR option, even with static NAT bindings (like a web server at home).
3. 在MP_JOIN消息的HMAC中包含SYN数据包的目标地址。由于攻击者需要更改目标地址才能执行所述攻击，因此保护目标地址可以防止攻击。它不允许通过ADD_ADDR选项中的地址访问NAT后面的主机，即使使用静态NAT绑定（如家庭中的web服务器）。
Of the options described above, option 2 is recommended as it achieves a higher security level while preserving the required functionality (i.e., NAT compatibility).
在上述选项中，建议使用选项2，因为它在保持所需功能（即NAT兼容性）的同时实现了更高的安全级别。
Summary of the attack:
攻击摘要：
Type of attack: MPTCP denial-of-service attack, preventing the hosts from creating new subflows
攻击类型：MPTCP拒绝服务攻击，阻止主机创建新的子流
Type of attacker: off-path active attacker
攻击者类型：非路径活动攻击者
Description:
说明：
As currently specified, the initial SYN+MP_JOIN message of the 3-way handshake for additional subflows creates state in the host receiving the message. This is because the SYN+MP_JOIN contains the 32-bit token that allows the receiver to identify the MPTCP session and the 32-bit random nonce used in the HMAC calculation. As this information is not re-sent in the third ACK of the 3-way handshake, a host must create state upon reception of a SYN+MP_JOIN.
按照目前的规定，附加子流的3路握手的初始SYN+MP_JOIN消息在接收消息的主机中创建状态。这是因为SYN+MP_连接包含32位令牌，允许接收器识别MPTCP会话和HMAC计算中使用的32位随机nonce。由于此信息不会在三向握手的第三个ACK中重新发送，因此主机必须在接收到SYN+MP_连接时创建状态。
Assume that an MPTCP session exists between Host A and Host B, with tokens TA and TB. An attacker, sending a SYN+MP_JOIN to Host B, with the valid token TB, will trigger the creation of state on Host B. The number of these half-open connections a host can store per MPTCP session is limited by a certain number and is implementation-dependent. The attacker can simply exhaust this limit by sending multiple SYN+MP_JOINs with different 5-tuples. The (possibly forged) source address of the attack packets will typically correspond to an address that is not in use, or else, the SYN/ACK sent by Host B would elicit a RST from the impersonated node, thus removing the corresponding state at Host B. Further discussion of traditional SYN flooding attacks and common mitigations can be found in [RFC4987].
假设主机A和主机B之间存在MPTCP会话，令牌为TA和TB。攻击者使用有效令牌TB向主机B发送SYN+MP_连接，将触发在主机B上创建状态。主机在每个MPTCP会话中可以存储的这些半开放连接的数量受到一定数量的限制，并且取决于实现。攻击者只需发送多个具有不同5元组的SYN+MP_联接，即可达到此限制。攻击数据包的（可能伪造的）源地址通常与未使用的地址相对应，否则，主机B发送的SYN/ACK将从模拟节点引发RST，从而删除主机B处的相应状态。有关传统SYN洪泛攻击和常见缓解措施的进一步讨论，请参阅[RFC4987]。
This effectively prevents Host A from sending any more SYN+MP_JOINs to Host B, as the number of acceptable half-open connections per MPTCP session on Host B has been exhausted.
这有效地防止了主机A向主机B发送更多的SYN+MP_连接，因为主机B上每个MPTCP会话可接受的半开放连接数已用尽。
The attacker needs to know the token TB in order to perform the described attack. This can be achieved if it is a partial-time on-path eavesdropper observing the 3-way handshake of the establishment of an additional subflow between Host A and Host B. If the attacker is never on-path, it has to guess the 32-bit token.
攻击者需要知道令牌TB才能执行所述攻击。如果是路径上的部分时间窃听者观察到主机a和主机B之间建立附加子流的3路握手，则可以实现此目的。如果攻击者从未在路径上，则必须猜测32位令牌。
The third packet of the 3-way handshake could be extended to also contain the 32-bit token and the random nonce that has been sent in the SYN+MP_JOIN. Further, Host B will have to generate its own random nonce in a reproducible fashion (e.g., a hash of the 5-tuple + initial sequence number + local secret). This will allow Host B to reply to a SYN+MP_JOIN without having to create state. Upon the reception of the third ACK, Host B can then verify the correctness of the HMAC and create the state.
3路握手的第三个数据包可以扩展为还包含在SYN+MP_连接中发送的32位令牌和随机nonce。此外，主机B必须以可再现的方式（例如，5元组的散列+初始序列号+本地秘密）生成其自己的随机nonce。这将允许主机B回复SYN+MP_连接，而无需创建状态。在接收到第三个ACK之后，主机B可以验证HMAC的正确性并创建状态。
Summary of the attack:
攻击摘要：
Type of attack: The attacker uses SYN+MP_JOIN messages to amplify the SYN flooding attack.
攻击类型：攻击者使用SYN+MP_JOIN消息放大SYN泛洪攻击。
Type of attacker: off-path active attacker
攻击者类型：非路径活动攻击者
Description:
说明：
SYN flooding attacks [RFC4987] use SYN messages to exhaust the server's resources and prevent new TCP connections. A common mitigation is the use of SYN cookies [RFC4987] that allow stateless processing of the initial SYN message.
SYN洪泛攻击[RFC4987]使用SYN消息耗尽服务器资源并阻止新的TCP连接。常见的缓解措施是使用SYN Cookie[RFC4987]，允许对初始SYN消息进行无状态处理。
With MPTCP, the initial SYN can be processed in a stateless fashion using the aforementioned SYN cookies. However, as described in the previous section, as currently specified, SYN+MP_JOIN messages are not processed in a stateless manner. This opens a new attack vector. The attacker can now open an MPTCP session by sending a regular SYN and creating the associated state but then sending as many SYN+MP_JOIN messages as supported by the server with different combinations of source address and source port, consuming the server's resources without having to create state in the attacker. This is an amplification attack, where the cost on the attacker side is only the cost of the state associated with the initial SYN while the cost on the server side is the state for the initial SYN plus all the state associated with all the following SYN+MP_JOINs.
使用MPTCP，可以使用前面提到的SYN cookies以无状态方式处理初始SYN。但是，如前一节所述，按照当前的规定，SYN+MP_JOIN消息不会以无状态方式处理。这会打开一个新的攻击向量。攻击者现在可以通过发送常规SYN并创建关联状态来打开MPTCP会话，但随后可以使用源地址和源端口的不同组合发送服务器支持的尽可能多的SYN+MP_JOIN消息，从而消耗服务器资源，而无需在攻击者中创建状态。这是一种放大攻击，其中攻击者端的成本仅为与初始SYN关联的状态的成本，而服务器端的成本为初始SYN的状态加上与所有以下SYN+MP_连接关联的所有状态。
1. The solution described for the previous DoS attack on MP_JOIN would also prevent this attack.
1. 针对先前针对MP_JOIN的DoS攻击所描述的解决方案也可以防止此攻击。
2. Limiting the number of half-open subflows to a low number (e.g., three subflows) would also limit the impact of this attack.
2. 将半开子流的数量限制在较低的数量（例如，三个子流）也会限制此攻击的影响。
Summary of the attack:
攻击摘要：
Type of attack: An eavesdropper present in the initial handshake where the keys are exchanged can hijack the MPTCP session at any time in the future.
攻击类型：在交换密钥的初始握手中出现的窃听者可以在将来的任何时候劫持MPTCP会话。
Type of attacker: partial-time on-path eavesdropper
攻击者类型：部分时间路径窃听器
Description:
说明：
In this case, the attacker is present along the path when the initial 3-way handshake takes place and therefore is able to learn the keys used in the MPTCP session. This allows the attacker to move away from the MPTCP session path and still be able to hijack the MPTCP session in the future. This vulnerability was readily identified when designing the MPTCP security solution [RFC6181], and the threat was considered acceptable.
在这种情况下，当初始3向握手发生时，攻击者在路径上，因此能够学习MPTCP会话中使用的密钥。这使得攻击者能够离开MPTCP会话路径，并在将来仍然能够劫持MPTCP会话。在设计MPTCP安全解决方案[RFC6181]时，很容易识别出该漏洞，并且认为该威胁是可接受的。
There are many techniques that can be used to prevent this attack, and each of them represents different trade-offs. At this point, we limit ourselves to enumerate them and provide useful pointers.
有许多技术可以用来防止这种攻击，每种技术都代表着不同的权衡。在这一点上，我们仅限于列举它们并提供有用的指针。
1. Use of hash chains. The use of hash chains for MPTCP has been explored in [HASH-CHAINS].
1. 使用散列链。[hash-chains]中探讨了MPTCP哈希链的使用。
2. Use of SSL keys for MPTCP security as described in [MPTCP-SSL].
2. 如[MPTCP-SSL]中所述，为MPTCP安全性使用SSL密钥。
3. Use of Cryptographically Generated Addresses (CGAs) for MPTCP security. CGAs [RFC3972] have been used in the past to secure multi-addressed protocols like Shim6 [RFC5533].
3. 使用加密生成的地址（CGA）实现MPTCP安全。CGA[RFC3972]过去曾用于保护多址协议，如Shim6[RFC5533]。
4. Use of tcpcrypt [TCPCRYPT].
4. 使用tcpcrypt[tcpcrypt]。
5. Use of DNSSEC. DNSSEC has been proposed to secure the Mobile IP protocol [DNSSEC].
5. DNSSEC的使用。建议使用DNSSEC保护移动IP协议[DNSSEC]。
Summary of the attack:
攻击摘要：
Type of attack: An attacker that can intercept the SYN/JOIN message can alter the source address being added.
攻击类型：能够截获SYN/JOIN消息的攻击者可以更改所添加的源地址。
Type of attacker: partial-time on-path eavesdropper
攻击者类型：部分时间路径窃听器
Description:
说明：
The attacker is present along the path when the SYN/JOIN exchange takes place. This allows the attacker to add any new address it wants to by simply substituting the source address of the SYN/JOIN packet for one it chooses. This vulnerability was readily identified when designing the MPTCP security solution [RFC6181], and the threat was considered acceptable.
发生SYN/JOIN交换时，攻击者在路径上。这使得攻击者只需将SYN/JOIN数据包的源地址替换为其选择的地址，即可添加任何想要添加的新地址。在设计MPTCP安全解决方案[RFC6181]时，很容易识别出该漏洞，并且认为该威胁是可接受的。
It should be noted that this vulnerability is fundamental due to the NAT support requirement. In other words, MPTCP must work through NATs in order to be deployable in the current Internet. NAT behavior is unfortunately indistinguishable from this attack. It is impossible to secure the source address, since doing so would prevent MPTCP from working through NATs. This basically implies that the solution cannot rely on securing the address. A more promising approach would be to look into securing the payload exchanged and
应该注意的是，由于NAT支持需求，此漏洞是根本性的。换句话说，MPTCP必须通过NAT工作，才能在当前互联网上部署。不幸的是，NAT行为与此攻击无法区分。不可能保护源地址，因为这样做会阻止MPTCP通过NAT工作。这基本上意味着解决方案不能依赖于保护地址。一个更有希望的方法是研究如何保护交换的有效载荷和数据
thus limiting the impact that the attack would have in the communication (e.g., tcpcrypt [TCPCRYPT] or similar).
从而限制攻击对通信的影响（例如，tcpcrypt[tcpcrypt]或类似）。
The current MPTCP specification [RFC6824] is Experimental. There is an ongoing effort to move it to Standards Track. We believe that the work on MPTCP security should follow two threads:
当前的MPTCP规范[RFC6824]是实验性的。目前正在努力将其纳入标准轨道。我们认为，MPTCP安全工作应遵循两条主线：
o The work on improving MPTCP security so that the MPTCP specification [RFC6824] can become a Standards Track document.
o 改进MPTCP安全性的工作，以便MPTCP规范[RFC6824]能够成为标准跟踪文档。
o The work on analyzing possible additional security enhancements to provide a more secure version of MPTCP.
o 分析可能的附加安全增强以提供更安全的MPTCP版本的工作。
We expand on these in the following subsections.
我们将在以下小节中对此进行详细介绍。
We believe that in order for MPTCP to progress to Standards Track, the ADD_ADDR attack must be addressed. We believe that the solution that should be adopted in order to deal with this attack is to include an HMAC to the ADD_ADDR message (with the address being added used as input to the HMAC as well as the key). This would make the ADD_ADDR message as secure as the JOIN message. In addition, this implies that if we implement a more secure way to create the key used in the MPTCP connection, then the security of both the MP_JOIN and the ADD_ADDR messages is automatically improved (since both use the same key in the HMAC).
我们认为，为了使MPTCP向标准轨道发展，必须解决ADD_ADDR攻击。我们认为，为了应对这种攻击，应该采取的解决方案是在ADD_ADDR消息中包含一个HMAC（添加的地址用作HMAC的输入以及密钥）。这将使ADD_ADDR消息与JOIN消息一样安全。此外，这意味着如果我们实现一种更安全的方法来创建MPTCP连接中使用的密钥，那么MP_JOIN和ADD_ADDR消息的安全性都会自动提高（因为两者在HMAC中使用相同的密钥）。
We believe that this is enough for MPTCP to progress as a Standards Track document because the security level is similar to single-path TCP per our previous analysis. Moreover, the security level achieved with these changes is exactly the same as other Standards Track documents. In particular, this would be the same security level as SCTP with dynamic addresses as defined in [RFC5061]. The Security Considerations section of RFC 5061 (which is a Standards Track document) reads:
我们相信这对于MPTCP作为标准跟踪文档的发展来说已经足够了，因为根据我们之前的分析，安全级别类似于单路径TCP。此外，通过这些更改实现的安全级别与其他标准跟踪文档完全相同。特别是，这将与具有[RFC5061]中定义的动态地址的SCTP具有相同的安全级别。RFC 5061（标准跟踪文件）的安全注意事项部分如下：
The addition and or deletion of an IP address to an existing association does provide an additional mechanism by which existing associations can be hijacked. Therefore, this document requires the use of the authentication mechanism defined in [RFC4895] to limit the ability of an attacker to hijack an association.
向现有关联添加和/或删除IP地址确实提供了一种额外的机制，可以通过该机制劫持现有关联。因此，本文档要求使用[RFC4895]中定义的身份验证机制来限制攻击者劫持关联的能力。
Hijacking an association by using the addition and deletion of an IP address is only possible for an attacker who is able to intercept the initial two packets of the association setup when
只有能够在以下情况下截获关联设置的最初两个数据包的攻击者才可能通过添加和删除IP地址劫持关联：
the SCTP-AUTH extension is used without pre-shared keys. If such a threat is considered a possibility, then the [RFC4895] extension MUST be used with a preconfigured shared endpoint pair key to mitigate this threat.
使用SCTP-AUTH扩展时不使用预共享密钥。如果认为存在这种威胁，那么[RFC4895]扩展必须与预配置的共享端点对密钥一起使用，以缓解这种威胁。
This is the same security level that would be achieved by MPTCP with the addition of the ADD_ADDR security measure recommended in this document.
这与MPTCP通过添加本文件中建议的ADD_ADDR安全措施所达到的安全级别相同。
We also believe that is worthwhile to explore alternatives to secure MPTCP. As we identified earlier, the problem of securing JOIN messages is fundamentally incompatible with NAT support, so it is likely that a solution to this problem involves the protection of the data itself. Exploring the integration of MPTCP and approaches like tcpcrypt [TCPCRYPT] and exploring integration with SSL seem promising.
我们还认为，有必要探索安全MPTCP的替代方案。正如我们前面所指出的，保护连接消息的问题从根本上讲与NAT支持不兼容，因此解决此问题的方法可能涉及数据本身的保护。探索MPTCP与tcpcrypt[tcpcrypt]等方法的集成以及探索与SSL的集成似乎很有希望。
This whole document is about security considerations for MPTCP.
整个文档都是关于MPTCP的安全注意事项。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 3972，DOI 10.17487/RFC3972，2005年3月<http://www.rfc-editor.org/info/rfc3972>.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <http://www.rfc-editor.org/info/rfc4895>.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 4895，DOI 10.17487/RFC4895，2007年8月<http://www.rfc-editor.org/info/rfc4895>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <http://www.rfc-editor.org/info/rfc5061>.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 5061，DOI 10.17487/RFC5061，2007年9月<http://www.rfc-editor.org/info/rfc5061>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <http://www.rfc-editor.org/info/rfc5961>.
[RFC5961]Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，RFC 5961，DOI 10.17487/RFC5961，2010年8月<http://www.rfc-editor.org/info/rfc5961>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056]Larsen，M.和F.Gont，“运输协议端口随机化建议”，BCP 156，RFC 6056，DOI 10.17487/RFC6056，2011年1月<http://www.rfc-editor.org/info/rfc6056>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, <http://www.rfc-editor.org/info/rfc6528>.
[RFC6528]Gont，F.和S.Bellovin，“防御序列号攻击”，RFC 6528，DOI 10.17487/RFC6528，2012年2月<http://www.rfc-editor.org/info/rfc6528>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824]Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“多地址多路径操作的TCP扩展”，RFC 6824DOI 10.17487/RFC68242013年1月<http://www.rfc-editor.org/info/rfc6824>.
[DNSSEC] Kukec, A., Bagnulo, M., Ayaz, S., Bauer, C., and W. Eddy, "ROAM-DNSSEC: Route Optimization for Aeronautical Mobility using DNSSEC", 4th ACM International Workshop on Mobility in the Evolving Internet Architecture (MobiArch), 2009.
[DNSSEC]Kukec，A.，Bagnulo，M.，Ayaz，S.，Bauer，C.，和W.Eddy，“ROAM-DNSSEC：使用DNSSEC的航空机动性路线优化”，第四届ACM国际研讨会，关于不断发展的互联网架构中的机动性（MobiArch），2009年。
[HASH-CHAINS] Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security for multipath TCP: a constructive approach", International Journal of Internet Protocol Technology, Vol. 6, No. 3, 2011.
[HASH-CHAINS]Diez，J.，Bagnulo，M.，Valera，F.，和I.Vidal，“多路径TCP的安全：一种建设性方法”，国际互联网协议技术杂志，第6卷，第3期，2011年。
[MPTCP-SSL] Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP handshake with external keys", Work in Progress, draft-paasch-mptcp-ssl-00, October 2012.
[MPTCP-SSL]Paasch，C.和O.Bonaventure，“使用外部密钥保护多路径TCP握手”，正在进行的工作，草稿-Paasch-MPTCP-SSL-00，2012年10月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<http://www.rfc-editor.org/info/rfc4960>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，DOI 10.17487/RFC4987，2007年8月<http://www.rfc-editor.org/info/rfc4987>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的三级多主Shim协议”，RFC 5533，DOI 10.17487/RFC5533，2009年6月<http://www.rfc-editor.org/info/rfc5533>.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011, <http://www.rfc-editor.org/info/rfc6181>.
[RFC6181]Bagnulo，M.，“具有多个地址的多路径操作的TCP扩展的威胁分析”，RFC 6181，DOI 10.17487/RFC6181，2011年3月<http://www.rfc-editor.org/info/rfc6181>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 6275，DOI 10.17487/RFC6275，2011年7月<http://www.rfc-editor.org/info/rfc6275>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <http://www.rfc-editor.org/info/rfc7039>.
[RFC7039]Wu，J.，Bi，J.，Bagnulo，M.，Baker，F.，和C.Vogt，Ed.，“源地址验证改进（SAVI）框架”，RFC 7039，DOI 10.17487/RFC7039，2013年10月<http://www.rfc-editor.org/info/rfc7039>.
[TCPCRYPT] Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, D., and Q. Slack, "Cryptographic protection of TCP Streams (tcpcrypt)", Work in Progress, draft-bittau-tcp-crypt-04, February 2014.
[TCPCRYPT]Bittau，A.，Boneh，D.，Hamburg，M.，Handley，M.，Mazieres，D.，和Q.Slack，“TCP流的加密保护（TCPCRYPT）”，正在进行的工作，草稿-Bittau-TCP-crypt-042014年2月。
Acknowledgements
致谢
We would like to thank Mark Handley for his comments on the attacks and countermeasures discussed in this document. We would also like to thank to Alissa Cooper, Phil Eardley, Yoshifumi Nishida, Barry Leiba, Stephen Farrell, and Stefan Winter for their comments and reviews.
我们要感谢Mark Handley对本文件中讨论的攻击和对策的评论。我们还要感谢Alissa Cooper、Phil Eardley、西田义夫、巴里·莱巴、斯蒂芬·法雷尔和斯特凡·温特的评论和评论。
Marcelo Bagnulo, Christoph Paasch, Oliver Bonaventure, and Costin Raiciu are partially funded by the EU Trilogy 2 project.
Marcelo Bagnulo、Christoph Paasch、Oliver Bonaventure和Costin Raiciu的部分资金来自欧盟三部曲2项目。
Authors' Addresses
作者地址
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
马德里卡洛斯三世大学。西班牙马德里勒加内斯30大学28911
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Christoph Paasch UCLouvain
克里斯托夫·帕什·乌鲁万
Email: christoph.paasch@gmail.com
Email: christoph.paasch@gmail.com
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont SI6 Networks/UTN-FRH Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Olivier Bonaventure UCLouvain Place Sainte Barbe, 2 Louvain-la-Neuve, 1348 Belgium
奥利维尔·博纳文图尔·乌鲁万广场圣巴伯，2卢万拉纽韦，1348比利时
Email: olivier.bonaventure@uclouvain.be
Email: olivier.bonaventure@uclouvain.be
Costin Raiciu Universitatea Politehnica Bucuresti Splaiul Independentei 313a Bucuresti Romania
科斯汀·莱丘大学波尔特尼卡独立学院313a罗马尼亚独立学院
Email: costin.raiciu@cs.pub.ro
Email: costin.raiciu@cs.pub.ro