Network Working Group R. Stewart
Request for Comments: 5062 Cisco Systems, Inc.
Category: Informational M. Tuexen
Muenster Univ. of Applied Sciences
G. Camarillo
Ericsson
September 2007
Network Working Group R. Stewart
Request for Comments: 5062 Cisco Systems, Inc.
Category: Informational M. Tuexen
Muenster Univ. of Applied Sciences
G. Camarillo
Ericsson
September 2007
Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
发现针对流控制传输协议（SCTP）的安全攻击和当前对策
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 4960, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960.
本文档描述了对SCTP的某些安全威胁。它还描述了缓解这些威胁的方法，特别是使用SCTP规范勘误表和问题备忘录（RFC 4460）中的技术。这些技术包括在RFC 4960中，它淘汰了RFC 2960。希望此信息将为SCTP规范勘误表和问题中阐述的许多最新要求提供一些有用的背景信息，并包括在RFC 4960中。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Address Camping or Stealing . . . . . . . . . . . . . . . . . 2
3. Association Hijacking 1 . . . . . . . . . . . . . . . . . . . 3
4. Association Hijacking 2 . . . . . . . . . . . . . . . . . . . 6
5. Bombing Attack (Amplification) 1 . . . . . . . . . . . . . . . 7
6. Bombing Attack (Amplification) 2 . . . . . . . . . . . . . . . 9
7. Association Redirection . . . . . . . . . . . . . . . . . . . 10
8. Bombing Attack (Amplification) 3 . . . . . . . . . . . . . . . 10
9. Bombing Attack (Amplification) 4 . . . . . . . . . . . . . . . 11
10. Bombing Attack (amplification) 5 . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Address Camping or Stealing . . . . . . . . . . . . . . . . . 2
3. Association Hijacking 1 . . . . . . . . . . . . . . . . . . . 3
4. Association Hijacking 2 . . . . . . . . . . . . . . . . . . . 6
5. Bombing Attack (Amplification) 1 . . . . . . . . . . . . . . . 7
6. Bombing Attack (Amplification) 2 . . . . . . . . . . . . . . . 9
7. Association Redirection . . . . . . . . . . . . . . . . . . . 10
8. Bombing Attack (Amplification) 3 . . . . . . . . . . . . . . . 10
9. Bombing Attack (Amplification) 4 . . . . . . . . . . . . . . . 11
10. Bombing Attack (amplification) 5 . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Stream Control Transmission Protocol, originally defined in [RFC2960], is a multi-homed transport protocol. As such, unique security threats exists that are addressed in various ways within the protocol itself. This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo [RFC4460]. These techniques are included in [RFC4960], which obsoletes [RFC2960]. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the [RFC4460] and included in [RFC4960].
最初在[RFC2960]中定义的流控制传输协议是一种多宿传输协议。因此，存在独特的安全威胁，这些威胁在协议本身中以各种方式得到解决。本文档描述了对SCTP的某些安全威胁。它还描述了缓解这些威胁的方法，特别是使用SCTP规范勘误表和问题备忘录[RFC4460]中的技术。这些技术包括在[RFC4960]中，它淘汰了[RFC2960]。希望这些信息将为[RFC4460]中阐述并包含在[RFC4960]中的许多最新需求提供一些有用的背景信息。
This work and some of the changes that went into [RFC4460] and [RFC4960] are much indebted to the paper on potential SCTP security risks [EFFECTS] by Aura, Nikander, and Camarillo. Without their work, some of these changes would remain undocumented and potential threats.
这项工作以及[RFC4460]和[RFC4960]中的一些变化很大程度上归功于Aura、Nikander和Camarillo关于潜在SCTP安全风险[影响]的论文。如果没有他们的工作，这些变化中的一些将仍然没有记录，并存在潜在的威胁。
The rest of this document will concentrate on the various attacks that were illustrated in [EFFECTS] and detail the preventative measures now in place, if any, within the current SCTP standards.
本文件的其余部分将集中于[效果]中说明的各种攻击，并详细说明当前SCTP标准中现有的预防措施（如有）。
This attack is a form of denial of service attack crafted around SCTP's multi-homing. In effect, an illegitimate endpoint connects to a server and "camps upon" or "holds up" a valid peer's address. This is done to prevent the legitimate peer from communicating with the server.
此攻击是围绕SCTP的多宿主而精心设计的拒绝服务攻击的一种形式。实际上，非法端点连接到服务器，并“集中”或“保留”有效对等方的地址。这样做是为了防止合法对等方与服务器通信。
+----------+ +----------+ +----------+
| Evil | | Server | | Client |
| IP-A=+------------+ +-----------+=IP-C & D |
| Attacker | | | | Victim |
+----------+ +----------+ +----------+
+----------+ +----------+ +----------+
| Evil | | Server | | Client |
| IP-A=+------------+ +-----------+=IP-C & D |
| Attacker | | | | Victim |
+----------+ +----------+ +----------+
Figure 1: Camping
图1：露营
Consider the scenario illustrated in Figure 1. The attacker legitimately holds IP-A and wishes to prevent the 'Client-Victim' from communicating with the 'Server'. Note also that the client is multi-homed. The attacker first guesses the port number our client will use in its association attempt. It then uses this port and sets up an association with the server listing not only IP-A but also IP-C in its initial INIT chunk. The server will respond and set up the association, noting that the attacker is multi-homed and holds both IP-A and IP-C.
考虑图1中所示的场景。攻击者合法持有IP-A，并希望阻止“客户端受害者”与“服务器”通信。还要注意，客户端是多宿主的。攻击者首先猜测客户端将在其关联尝试中使用的端口号。然后，它使用这个端口，并在其初始INIT块中设置与服务器的关联，不仅列出IP-A，还列出IP-C。服务器将响应并设置关联，注意攻击者是多宿主的，同时拥有IP-A和IP-C。
Next, the victim sends in an INIT message listing its two valid addresses, IP-C and IP-D. In response, it will receive an ABORT message with possibly an error code indicating that a new address was added in its attempt to set up an existing association (a restart with new addresses). At this point, 'Client-Victim' is now prevented from setting up an association with the server until the server realizes that the attacker does not hold the address IP-C at some future point by using a HEARTBEAT based mechanism. See the mitigation option subsection of this section.
接下来，受害者发送一条INIT消息，列出其两个有效地址IP-C和IP-D。作为响应，它将收到一条中止消息，其中可能包含一个错误代码，指示在尝试建立现有关联时添加了一个新地址（使用新地址重新启动）。在这一点上，“客户端受害者”现在被阻止与服务器建立关联，直到服务器意识到攻击者在将来某个时候使用基于心跳的机制不持有地址IP-C。见本节缓解方案小节。
This particular attack was discussed in detail on the SCTP implementors list in March of 2003. Out of that discussion, changes were made in the BSD implementation that are now present in [RFC4960]. In close examination, this attack depends on a number of specific things to occur.
2003年3月，SCTP实施者列表中详细讨论了这一特定攻击。在讨论之后，对BSD实现进行了更改，这些更改现在出现在[RFC4960]中。仔细检查，这种攻击取决于发生的一些特定事件。
1) The attacker must set up the association before the victim and must correctly guess the port number that the victim will use. If the victim uses any other port number the attack will fail.
1) 攻击者必须在受害者之前设置关联，并且必须正确猜测受害者将使用的端口号。如果受害者使用任何其他端口号，攻击将失败。
2) SCTP's existing HEARTBEAT mechanism as defined already in [RFC2960] will eventually catch this situation and abort the evil attacker's association. This may take several seconds based on default HEARTBEAT timers but the attacker himself will lose any association.
2) [RFC2960]中已经定义的SCTP现有心跳机制最终将捕获这种情况并中止恶意攻击者的关联。根据默认的心跳计时器，这可能需要几秒钟，但攻击者自己将失去任何关联。
3) If the victim is either not multi-homed, or the address set that it uses is completely camped upon by the attacker (in our example if the attacker had included IP-D in its INIT as well), then the client's INIT message would initiate an association between the client and the server while destroying the association between the attacker and the server. From the servers' perspective, this is a restart of the association.
3) 如果受害者不是多宿的，或者它使用的地址集完全被攻击者占据（在我们的示例中，如果攻击者在其INIT中也包含了IP-D），然后，客户端的INIT消息将启动客户端和服务器之间的关联，同时破坏攻击者和服务器之间的关联。从服务器的角度来看，这是关联的重新启动。
[RFC4960] adds a new set of requirements to better counter this attack. In particular, the HEARTBEAT mechanism was modified so that addresses unknown to an endpoint (i.e., presented in an INIT with no pre-knowledge given by the application) enter a new state called "UNCONFIRMED". During the time that any address is UNCONFIRMED and yet considered available, heartbeating will be done on those UNCONFIRMED addresses at an accelerated rate. This will lessen the time that an attacker can "camp" on an address. In particular, the rate of heartbeats to UNCONFIRMED addresses is done every RTO. Along with this expanded rate of heartbeating, a new 64-bit random nonce is required to be inside HEARTBEATs to UNCONFIRMED addresses. In the HEARTBEAT-ACK, the random nonce must match the value sent in the HEARTBEAT before an address can leave the UNCONFIRMED state. This will prevent an attacker from generating false HEARTBEAT-ACKs with the victim's source address(es). In addition, clients that do not need to use a specific port number should choose their port numbers on a random basis. This makes it hard for an attacker to guess that number.
[RFC4960]增加了一组新的要求，以更好地应对这种攻击。特别是，对心跳机制进行了修改，以使端点未知的地址（即，在应用程序未给出预先知识的INIT中呈现）进入称为“未确认”的新状态。在任何地址未经确认且被认为可用的期间，将加速对这些未经确认的地址进行心跳。这将减少攻击者在地址上“扎营”的时间。特别是，每个RTO都会对未确认地址的心跳速率进行检测。除了此扩展的心跳速率之外，还需要在未确认地址的心跳内添加一个新的64位随机nonce。在HEARTBEAT-ACK中，在地址可以离开未确认状态之前，随机nonce必须与HEARTBEAT中发送的值匹配。这将防止攻击者使用受害者的源地址生成虚假心跳确认。此外，不需要使用特定端口号的客户端应随机选择其端口号。这使得攻击者很难猜出这个数字。
Association hijacking is the ability of some other user to assume the session created by another endpoint. In cases of a true man-in-the-middle, only a strong end-to-end security model can prevent this. However, with the addition of the SCTP extension specified in [RFC5061], an endpoint that is NOT a man-in-the-middle may be able to assume another endpoint's association.
关联劫持是其他一些用户假设由另一个端点创建的会话的能力。对于真正的中间人，只有强大的端到端安全模型才能防止这种情况。但是，通过添加[RFC5061]中指定的SCTP扩展，一个不是中间人的端点可以假设另一个端点的关联。
The attack is made possible by any mechanism that lets an endpoint acquire some other IP address that was recently in use by an SCTP endpoint. For example, DHCP may be used in a mobile network with short IP address lifetimes to reassign IP addresses to migrant hosts.
任何允许端点获取SCTP端点最近使用的其他IP地址的机制都可能导致攻击。例如，DHCP可用于IP地址生存期较短的移动网络中，以将IP地址重新分配给迁移主机。
IP-A DHCP-Server's Peer-Server
|
|
1 |-DHCP-Rel(IP-A)---->|
2 |------ASCONF(ADD-IP(IP-B), DEL-IP(IP-A)---->XXlost
time
|
|-DHCP-new-net------>|
3 |<---Assign (IP-A)
|
4 |<------------Tag:X-DATA()------------------
|
|-------------INIT()------------------------>
5 |<------------INIT-ACK()---------------------
|
6 |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------>
IP-A DHCP-Server's Peer-Server
|
|
1 |-DHCP-Rel(IP-A)---->|
2 |------ASCONF(ADD-IP(IP-B), DEL-IP(IP-A)---->XXlost
time
|
|-DHCP-new-net------>|
3 |<---Assign (IP-A)
|
4 |<------------Tag:X-DATA()------------------
|
|-------------INIT()------------------------>
5 |<------------INIT-ACK()---------------------
|
6 |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------>
Figure 2: Association Hijack via DHCP
图2：通过DHCP的关联劫持
At point 1, our valid client releases the IP address IP-A. It presumably acquires a new address (IP-B) and sends an ASCONF to ADD the new address and delete to old address at point 2, but this packet is lost. Thus, our peer (Peer-Server) has no idea that the former peer is no longer at IP-A. Now at point 3, a new "evil" peer obtains an address via DHCP and it happens to get the re-assigned address IP-A. Our Peer-Server sends a chunk of DATA at point 4. This reveals to the new owner of IP-A that the former owner of IP-A had an association with Peer-Server. So at point 5, the new owner of IP-A sends an INIT. The INIT-ACK is sent back and inside it is a COOKIE. The cookie would of course hold tie-tags, which would list both sets of tags that could then be used at point 6 to add in any other IP addresses that the owner of IP-A holds and thus acquire the association.
在第1点，我们的有效客户端释放IP地址IP-A。它可能会获取一个新地址（IP-B），并在第2点发送ASCONF以添加新地址并删除旧地址，但该数据包丢失。因此，我们的对等方（对等服务器）不知道前一个对等方不再位于IP-A。现在在第3点，一个新的“邪恶”对等方通过DHCP获得一个地址，它恰好获得重新分配的地址IP-A。我们的对等服务器在第4点发送一块数据。这向IP-A的新所有者揭示了IP-A的前所有者与对等服务器有关联。因此，在第5点，IP-A的新所有者发送一个INIT。INIT-ACK被发回，里面是一个COOKIE。cookie当然会保存tie标记，这将列出两组标记，然后在第6点使用它们添加IP-A所有者持有的任何其他IP地址，从而获得关联。
It should be noted that this attack is possible in general whenever the attacker is able to send packets with source address IP-A and receive packets with destination address IP-A.
应该注意的是，只要攻击者能够发送源地址为IP-A的数据包并接收目标地址为IP-A的数据包，通常都可能发生这种攻击。
This attack depends on a number of events:
此攻击取决于多个事件：
1) Both endpoints must support the SCTP extension specified in [RFC5061].
1) 两个端点都必须支持[RFC5061]中指定的SCTP扩展。
2) One of the endpoints must be using the SCTP extension for mobility specified in [RFC5061].
2) 其中一个端点必须使用[RFC5061]中指定的用于移动性的SCTP扩展。
3) The IP address must be acquired in such a way as to make the endpoint the owner of that IP address as far as the network is concerned.
3) 获取IP地址的方式必须使端点成为网络中该IP地址的所有者。
4) The true peer must not receive the ASCONF packet that deletes IP-A and adds its new address to the peer before the new "evil" peer gets control of the association.
4) 在新的“邪恶”对等方控制关联之前，真正的对等方不得接收删除IP-A并将其新地址添加到对等方的ASCONF数据包。
5) The new "evil" peer must have an alternate address, aside from the IP-A that it can add to the association, so it can delete IP-A, preventing the real peer from re-acquiring the association when it finally retransmits the ASCONF (from step 2).
5) 除了可以添加到关联中的IP-A之外，新的“邪恶”对等方必须有一个备用地址，以便它可以删除IP-A，防止真正的对等方在最终重新传输ASCONF时重新获取关联（从步骤2开始）。
[RFC4960] adds a new counter measure to this threat. It is now required that Tie-Tags in the State-Cookie parameter not be the actual tags. Instead, a new pair of two 32-bit nonces must be used to represent the real tags within the association. This prevents the attacker from acquiring the real tags and thus prevents this attack. Furthermore, the use of the SCTP extension specified in [RFC5061] requires the use of the authentication mechanism defined in [RFC4895]. This requires the attacker to be able to capture the traffic during the association setup. If in addition an endpoint-pair shared key is used, capturing or intercepting these setup messages does not enable the attacker to hijack the association.
[RFC4960]为这一威胁添加了新的应对措施。现在要求State Cookie参数中的Tie标记不是实际的标记。相反，必须使用一对新的两个32位nonce来表示关联中的实际标记。这可以防止攻击者获取真正的标记，从而防止这种攻击。此外，使用[RFC5061]中指定的SCTP扩展需要使用[RFC4895]中定义的身份验证机制。这要求攻击者能够在关联设置过程中捕获流量。如果另外使用了端点对共享密钥，则捕获或拦截这些设置消息不会使攻击者劫持关联。
Association hijacking is the ability of some other user to assume the session created by another endpoint. In cases where an attacker can send packets using the victims IP-address as a source address and can receive packets with the victims' address as a destination address, the attacker can easily restart the association. If the peer does not pay attention to the restart notification, the attacker has taken over the association.
关联劫持是其他一些用户假设由另一个端点创建的会话的能力。如果攻击者可以使用受害者IP地址作为源地址发送数据包，并可以接收以受害者地址作为目标地址的数据包，则攻击者可以轻松地重新启动关联。如果对等方不注意重启通知，则攻击者已接管关联。
Assume that an endpoint E1 having an IP-address A has an SCTP association with endpoint E2. After the attacker is able to receive packets to destination address A and send packets with source address A, the attacker can perform a full four-way handshake using the IP-addresses and port numbers from the received packet. E2 will consider this a restart of the association. If and only if the SCTP user of E2 does not process the restart notification, the user will not recognize that the association just restarted. From this perspective, the association has been hijacked.
假设具有IP地址A的端点E1与端点E2具有SCTP关联。在攻击者能够将数据包接收到目标地址A并发送带有源地址A的数据包后，攻击者可以使用接收到的数据包的IP地址和端口号执行完整的四向握手。E2将考虑这一关联的重新启动。如果且仅当E2的SCTP用户不处理重新启动通知时，用户将无法识别关联刚刚重新启动。从这个角度来看，协会被劫持了。
This attack depends on a number of circumstances:
此攻击取决于多种情况：
1) The IP address must be acquired in such a way as to make the evil endpoint the owner of that IP address as far as the network or local LAN is concerned.
1) 就网络或本地LAN而言，IP地址的获取方式必须使恶意端点成为该IP地址的所有者。
2) The attacker must receive a packet belonging to the association or connection.
2) 攻击者必须接收属于该关联或连接的数据包。
3) The other endpoint's user does not pay attention to restart notifications.
3) 另一个端点的用户不注意重新启动通知。
It is important to note that this attack is not based on a weakness of the protocol, but on the ignorance of the upper layer. This attack is not possible if the upper layer processes the restart notifications provided by SCTP as described in section 10 of [RFC2960] or [RFC4960]. Note that other IP protocols may also be affected by this attack.
需要注意的是，这种攻击不是基于协议的弱点，而是基于上层的无知。如果上层如[RFC2960]或[RFC4960]第10节所述处理SCTP提供的重启通知，则不可能进行此攻击。请注意，其他IP协议也可能受到此攻击的影响。
The bombing attack is a method to get a server to amplify packets to an innocent victim.
轰炸攻击是一种让服务器向无辜受害者放大数据包的方法。
This attack is performed by setting up an association with a peer and listing the victims IP address in the INIT's list of addresses. After the association is setup, the attacker makes a request for a large data transfer. After making the request, the attacker does not acknowledge data sent to it. This then causes the server to re-transmit the data to the alternate address, i.e., that of the victim.
此攻击通过与对等方建立关联并在INIT的地址列表中列出受害者IP地址来执行。建立关联后，攻击者会请求进行大规模数据传输。发出请求后，攻击者不会确认发送给它的数据。然后，这会导致服务器将数据重新传输到备用地址，即受害者的地址。
After waiting an appropriate time period, the attacker acknowledges the data for the victim. At some point, the attackers address is considered unreachable since only data sent to the victims address is acknowledged. At this point, the attacker can send strategic acknowledgments so that the server continues to send data to the victim.
在等待适当的时间段后，攻击者会确认受害者的数据。在某些情况下，攻击者地址被认为是不可访问的，因为只有发送到受害者地址的数据才被确认。此时，攻击者可以发送策略确认，以便服务器继续向受害者发送数据。
Alternatively, instead of stopping the sending of SACKs to enforce a path failover, the attacker can use the ADD-IP extension to add the address of the victim and make that address the primary path.
或者，攻击者可以使用ADD-IP扩展添加受害者的地址，并使该地址成为主路径，而不是停止发送SACK以强制执行路径故障切换。
This attack depends on a number of circumstances:
此攻击取决于多种情况：
1) The victim must NOT support SCTP, otherwise it would respond with an "out of the blue" (OOTB) abort.
1) 受害者不得支持SCTP，否则它将以“出乎意料”（OOTB）中止响应。
2) The attacker must time its sending of acknowledgments correctly in order to get its address into the failed state and the victim's address as the only valid alternative.
2) 攻击者必须正确确定其发送确认的时间，以便将其地址置于失败状态，并将受害者地址作为唯一有效的替代地址。
3) The attacker must guess TSN values that are accepted by the receiver once the bombing begins since it must acknowledge packets it is no longer seeing.
3) 一旦轰炸开始，攻击者必须猜测接收器接受的TSN值，因为它必须确认不再看到的数据包。
[RFC4960] makes two changes to prevent this attack. First, it details proper handling of ICMP messages. With SCTP, the ICMP messages provide valuable clues to the SCTP stack that can be verified with the tags for authenticity. Proper handling of an ICMP protocol unreachable (or equivalent) would cause the association setup by the attacker to be immediately failed upon the first retransmission to the victim's address.
[RFC4960]进行两项更改以防止此攻击。首先，它详细说明了ICMP消息的正确处理。有了SCTP，ICMP消息为SCTP堆栈提供了有价值的线索，可以使用标记验证其真实性。正确处理无法访问（或等效）的ICMP协议将导致攻击者在首次重新传输到受害者地址时立即失败关联设置。
The second change made in [RFC4960] is the requirement that no address that is not CONFIRMED is allowed to have DATA chunks sent to it. This prevents the switch-over to the alternate address from occurring, even when ICMP messages are lost in the network and prevents any DATA chunks from being sent to any other destination other then the attacker itself. This also prevents the alternative way of using ADD-IP to add the new address and make it the primary address.
[RFC4960]中的第二个更改是要求不允许未确认的地址向其发送数据块。这可以防止切换到备用地址，即使ICMP消息在网络中丢失，也可以防止任何数据块被发送到攻击者自身以外的任何其他目的地。这也防止了使用ADD-IP添加新地址并使其成为主地址的替代方法。
An SCTP implementation should abort the association if it receives a SACK acknowledging a TSN that has not been sent. This makes TSN guessing for the attacker quite hard because if the attacker acknowledges one TSN too fast, the association will be aborted.
如果SCTP实现接收到确认尚未发送TSN的SACK，则应中止关联。这使得攻击者很难猜测TSN，因为如果攻击者以过快的速度确认一个TSN，关联将被中止。
This attack allows an attacker to use an arbitrary SCTP endpoint to send multiple packets to a victim in response to one packet.
此攻击允许攻击者使用任意SCTP端点向受害者发送多个数据包以响应一个数据包。
The attacker sends an INIT listing multiple IP addresses of the victim in the INIT's list of addresses to an arbitrary endpoint. Optionally, it requests a long cookie lifetime. Upon reception of the INIT-ACK, it stores the cookie and sends it back to the other endpoint. When the other endpoint receives the COOKIE, it will send back a COOKIE-ACK to the attacker and up to HB.Max.Burst HEARTBEATS to the victim's address(es) (to confirm these addresses). The victim responds with ABORTs or ICMP messages resulting in the removal of the TCB at the other endpoint. The attacker can now resend the stored cookie as long as it is valid, and this will again result in up to HB.Max.Burst HEARTBEATs sent to the victim('s).
攻击者向任意端点发送一个INIT，列出INIT地址列表中受害者的多个IP地址。或者，它请求较长的cookie生存期。在接收到INIT-ACK后，它存储cookie并将其发送回另一个端点。当另一个端点接收到COOKIE时，它将向攻击者发送COOKIE-ACK，并向受害者的地址发送高达HB.Max.Burst心跳（以确认这些地址）。受害者以中止或ICMP消息进行响应，从而在另一个端点上删除TCB。只要存储的cookie有效，攻击者现在就可以重新发送该cookie，这将再次导致向受害者发送高达HB.Max.Burst的心跳。
The multiplication factor is limited by the number of addresses of the victim and of the endpoint HB.Max.Burst. Also, the shorter the cookie lifetime, the earlier the attacker has to go through the initial stage of sending an INIT instead of just sending the COOKIE. It should also be noted that the attack is more effective if large HEARTBEATs are used for path confirmation.
乘法因子受受害者和端点HB.Max.Burst的地址数限制。而且，cookie的生存期越短，攻击者就越早完成发送INIT的初始阶段，而不仅仅是发送cookie。还应注意的是，如果使用大心跳进行路径确认，则攻击更有效。
To limit the effectiveness of this attack, the new parameter HB.Max.Burst was introduced in [RFC4960] and an endpoint should:
为了限制此攻击的有效性，[RFC4960]中引入了新参数HB.Max.Burst，端点应：
1) not allow very large cookie lifetimes, even if they are requested.
1) 不允许非常大的cookie生存期，即使它们被请求。
2) not use larger HB.Max.Burst parameter values than recommended. Note that an endpoint may decide to send only one Heartbeat per RTT instead of the maximum (i.e., HB.Max.Burst). An endpoint that chooses this approach will however slow down detection of endpoints camping on valid addresses.
2) 不要使用比推荐值更大的HB.Max.Burst参数值。注意，端点可能决定每个RTT只发送一个心跳信号，而不是最大值（即HB.Max.Burst）。然而，选择这种方法的端点将减慢对有效地址上的端点的检测。
3) not use large HEARTBEATs for path confirmation.
3) 不使用大心跳进行路径确认。
This attack allows an attacker to wrongly set up an association to a different endpoint.
此攻击允许攻击者错误地设置与不同端点的关联。
The attacker sends an INIT sourced from port 'X' and directed towards port 'Y'. When the INIT-ACK is returned, the attacker sends the COOKIE-ECHO chunk and either places a different destination or source port in the SCTP common header, i.e., X+1 or Y+1. This possibly sets up the association using the modified port numbers.
攻击者发送源于端口“X”并指向端口“Y”的INIT。当返回INIT-ACK时，攻击者发送COOKIE-ECHO块，并在SCTP公共头中放置不同的目标或源端口，即X+1或Y+1。这可能会使用修改后的端口号建立关联。
This attack depends on the failure of an SCTP implementation to store and verify the ports within the COOKIE structure.
此攻击取决于SCTP实现无法在COOKIE结构中存储和验证端口。
This attack is easily defeated by an implementation including the ports of both the source and destination within the COOKIE. If the source and destination ports do not match those within the COOKIE chunk when the COOKIE is returned, the SCTP implementation silently discards the invalid COOKIE.
通过在COOKIE中包含源端口和目标端口的实现，可以轻松击败此攻击。如果返回COOKIE时源端口和目标端口与COOKIE块中的端口不匹配，则SCTP实现会自动丢弃无效的COOKIE。
This attack allows an attacker to use an SCTP endpoint to send a large number of packets in response to one packet.
此攻击允许攻击者使用SCTP端点发送大量数据包以响应一个数据包。
The attacker sends a packet to an SCTP endpoint, which requires the sending of multiple chunks. If the SCTP endpoint does not support bundling on the sending side, it might send each chunk per packet. These packets can either be sent to a victim by using the victim's address as the sources address, or it can be considered an attack against the network. Since the chunks, which need to be sent in response to the received packet, may not fit into one packet, an endpoint supporting bundling on the sending side might send multiple packets.
攻击者向SCTP端点发送数据包，这需要发送多个数据块。如果SCTP端点不支持发送端的绑定，它可能会发送每个数据包的每个数据块。这些数据包可以通过使用受害者的地址作为源地址发送给受害者，也可以被视为对网络的攻击。由于需要响应于所接收的分组而发送的区块可能不适合于一个分组，因此在发送端支持捆绑的端点可能发送多个分组。
Examples of these packets are packets containing a lot of unknown chunks that require an ERROR chunk to be sent, known chunks that initiate the sending of ERROR chunks, packets containing a lot of HEARTBEAT chunks, and so on.
这些数据包的示例包括包含大量未知数据块（需要发送错误数据块）、启动错误数据块发送的已知数据块、包含大量心跳数据块的数据包，等等。
This attack depends on the fact that the SCTP endpoint does not support bundling on the sending side or provides a bad implementation of bundling on the sending side.
此攻击取决于以下事实：SCTP端点不支持发送端的绑定，或者在发送端提供了错误的绑定实现。
First of all, path verification must happen before sending chunks other than HEARTBEATs for path verification. This ensures that the above attack cannot be used against other hosts. To avoid the attack, an SCTP endpoint should implement bundling on the sending side and should not send multiple packets in response. If the SCTP endpoint does not support bundling on the sending side, it should not send in general more than one packet in response to a received one. The details of the required handling are described in [RFC4960].
首先，路径验证必须在发送除心跳以外的块进行路径验证之前进行。这确保了上述攻击不能用于其他主机。为了避免攻击，SCTP端点应该在发送端实现绑定，并且不应该发送多个数据包作为响应。如果SCTP端点不支持发送端的绑定，则通常不应发送多个数据包来响应接收到的数据包。[RFC4960]中描述了所需处理的详细信息。
This attack allows an attacker to use an SCTP server to send a larger packet to a victim than it sent to the SCTP server.
此攻击允许攻击者使用SCTP服务器向受害者发送比发送到SCTP服务器的数据包更大的数据包。
The attacker sends packets using the victim's address as the source address containing an INIT chunk to an SCTP Server. The server then sends a packet containing an INIT-ACK chunk to the victim, which is most likely larger than the packet containing the INIT.
攻击者使用受害者地址作为包含INIT块的源地址向SCTP服务器发送数据包。然后，服务器向受害者发送一个包含INIT-ACK块的数据包，该数据包很可能比包含INIT的数据包大。
This attack is a byte and not a packet amplification attack and, without protocol changes, is hard to avoid. A possible method to avoid this attack would be the usage the PAD parameter defined in [RFC4820].
这种攻击是一种字节攻击，而不是数据包放大攻击，如果不更改协议，很难避免。避免这种攻击的一种可能方法是使用[RFC4820]中定义的PAD参数。
A server should be implemented in a way that the generated INIT-ACK chunks are as small as possible.
服务器的实现方式应确保生成的INIT-ACK块尽可能小。
This attack allows an attacker to use an SCTP endpoint to send a large number of packets in response to one packet.
此攻击允许攻击者使用SCTP端点发送大量数据包以响应一个数据包。
The attacker sends a packet to an SCTP endpoint, which requires the sending of multiple chunks. If the MTU towards the attacker is smaller than the MTU towards the victim, the victim might need to send more than one packet to send all the chunks. The difference between the MTUs might be extremely large if the attacker sends malicious ICMP packets to make use of the path MTU discovery.
攻击者向SCTP端点发送数据包，这需要发送多个数据块。如果攻击者的MTU小于受害者的MTU，那么受害者可能需要发送多个数据包来发送所有数据块。如果攻击者发送恶意ICMP数据包以利用路径MTU发现，MTU之间的差异可能非常大。
This attack depends on the fact that an SCTP implementation might not limit the number of response packets correctly.
此攻击取决于以下事实：SCTP实现可能无法正确限制响应数据包的数量。
First of all, path verification must happen before sending chunks other than HEARTBEATs for path verification. This makes sure that the above attack cannot be used against other hosts. To avoid the attack, an SCTP endpoint should not send multiple packets in response to a single packet. The chunks not fitting in this packet should be dropped.
首先，路径验证必须在发送除心跳以外的块进行路径验证之前进行。这确保了上述攻击不能用于其他主机。为了避免攻击，SCTP端点不应发送多个数据包来响应单个数据包。不适合此数据包的数据块应丢弃。
This document is about security; as such, there are no additional security considerations.
这份文件是关于安全的；因此，没有额外的安全考虑。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues", RFC 4460, April 2006.
[RFC4460]Stewart，R.，Arias Rodriguez，I.，Poon，K.，Caro，A.，和M.Tuexen，“流控制传输协议（SCTP）规范勘误表和问题”，RFC 44602006年4月。
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
[RFC4820]Tuexen，M.，Stewart，R.，和P.Lei，“流控制传输协议（SCTP）的填充块和参数”，RFC 4820，2007年3月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 48952007年8月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 50612007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, June 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年6月。
[EFFECTS] Aura, T., Nikander, P., and G. Camarillo, "Effects of Mobility and Multihoming on Transport-Layer Security", Security and Privacy 2004, IEEE Symposium , URL http:// research.microsoft.com/users/tuomaura/Publications/ aura-nikander-camarillo-ssp04.pdf, May 2004.
[效果]Aura，T.，Nikander，P.，和G.Camarillo，“移动性和多宿对传输层安全的影响”，安全和隐私2004年，IEEE研讨会，网址http://research.microsoft.com/users/tuomaura/Publications/Aura-Nikander-Camarillo-ssp04.pdf，2004年5月。
Authors' Addresses
作者地址
Randall R. Stewart Cisco Systems, Inc. 4785 Forest Drive Suite 200 Columbia, SC 29206 USA
Randall R.Stewart Cisco Systems，Inc.美国哥伦比亚森林大道200号4785室，邮编：29206
EMail: rrs@cisco.com
EMail: rrs@cisco.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
Michael Tuexen Muenster应用科学大学Stegerwaldstr。39 48565德国斯坦福德
EMail: tuexen@fh-muenster.de
EMail: tuexen@fh-muenster.de
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.