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
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.
Stewart, et al. Informational [Page 1]
RFC 5062 SCTP Security Attacks September 2007
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
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].
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.
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.
2. Address Camping or Stealing
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.
Stewart, et al. Informational [Page 2]
RFC 5062 SCTP Security Attacks September 2007
2.1. Attack Details
+----------+ +----------+ +----------+
| Evil | | Server | | Client |
| IP-A=+------------+ +-----------+=IP-C & D |
| Attacker | | | | Victim |
+----------+ +----------+ +----------+
Figure 1: Camping
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.
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.
2.2. Analysis
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.
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.
Stewart, et al. Informational [Page 3]
RFC 5062 SCTP Security Attacks September 2007
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.
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.
2.3. Mitigation Option
[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.