draft-ietf-tsvwg-sctpthreat-00.txt   draft-ietf-tsvwg-sctpthreat-01.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: July 22, 2006 M. Tuexen Intended status: Informational M. Tuexen
Muenster Univ. of Applied Sciences Expires: February 8, 2007 Muenster Univ. of Applied Sciences
G. Camarillo G. Camarillo
Ericsson Ericsson
January 18, 2006 August 7, 2006
Stream Control Transmission Protocol (SCTP) Security Threats Security Attacks Found Against SCTP and Current Countermeasures
draft-ietf-tsvwg-sctpthreat-00.txt draft-ietf-tsvwg-sctpthreat-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 22, 2006. This Internet-Draft will expire on February 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Stream Control Transmission Protocol RFC2960 [2] is a multi-homed Stream Control Transmission Protocol RFC2960 [RFC2960] is a multi-
transport protocol. As such, unique security threats exists that are homed transport protocol. As such, unique security threats exists
addressed in various ways within the protocol itself. This document that are addressed in various ways within the protocol itself. This
attempts to detail the known security threats and there document attempts to detail the known security threats and there
countermeasures as detailed in the current version of the SCTP countermeasures as detailed in the current version of the SCTP
Implementors guide (SCTP-IG). It is hoped that this information will Implementors guide (SCTP-IG). It is hoped that this information will
provide some useful background information for many of the newest provide some useful background information for many of the newest
requirements spelled out in the SCTP-IG. requirements spelled out in the SCTP-IG.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Address Camping or stealing . . . . . . . . . . . . . . . . . 3 2. Address Camping or stealing . . . . . . . . . . . . . . . . . 3
3. Association hijacking 1 . . . . . . . . . . . . . . . . . . . 5 3. Association hijacking 1 . . . . . . . . . . . . . . . . . . . 5
4. Association hijacking 2 . . . . . . . . . . . . . . . . . . . 7 4. Association hijacking 2 . . . . . . . . . . . . . . . . . . . 7
5. Bombing attack (amplification) 1 . . . . . . . . . . . . . . . 7 5. Bombing attack (amplification) 1 . . . . . . . . . . . . . . . 8
6. Bombing attack (amplification) 2 . . . . . . . . . . . . . . . 9 6. Bombing attack (amplification) 2 . . . . . . . . . . . . . . . 9
7. Association redirection . . . . . . . . . . . . . . . . . . . 10 7. Association redirection . . . . . . . . . . . . . . . . . . . 10
8. Bombing attack (amplification) 3 . . . . . . . . . . . . . . . 10 8. Bombing attack (amplification) 3 . . . . . . . . . . . . . . . 10
9. Bombing attack (amplification) 4 . . . . . . . . . . . . . . . 11 9. Bombing attack (amplification) 4 . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
Stream Control Transmission Protocol RFC2960 [2] is a multi-homed Stream Control Transmission Protocol RFC2960 [RFC2960] is a multi-
transport protocol. As such, unique security threats exists that are homed transport protocol. As such, unique security threats exists
addressed in various ways within the protocol itself. This document that are addressed in various ways within the protocol itself. This
attempts to detail the known security threats and there document attempts to detail the known security threats and there
countermeasures as detailed in the current version of the SCTP countermeasures as detailed in the current version of the SCTP
Implementors guide (SCTP-IG). It is hoped that this information will Implementors guide (SCTP-IG). It is hoped that this information will
provide some useful background information for many of the newest provide some useful background information for many of the newest
requirements spelled out in the SCTP-IG. requirements spelled out in the SCTP-IG.
This work and some of the changes that went into the tenth version of This work and some of the changes that went into the tenth version of
the SCTP-IG are much indebted to the paper on potential SCTP security the SCTP-IG are much indebted to the paper on potential SCTP security
risks Effects [1] by Aura, Nikander and Camarillo. Without there risks Effects [effects] by Aura, Nikander and Camarillo. Without
work some of these changes would remain undocumented and potential there work some of these changes would remain undocumented and
threats. potential threats.
The rest of this document will concentrate on the various attacks The rest of this document will concentrate on the various attacks
that were illustrated in Effects [1] and detail what preventative that were illustrated in Effects [effects] and detail what
measures are now in place within the current SCTP standards (if any). preventative measures are now in place within the current SCTP
standards (if any).
2. Address Camping or stealing 2. Address Camping or stealing
This attack is a form of denial of service attack crafted around This attack is a form of denial of service attack crafted around
SCTP's multi-homing. In effect an illegitimate endpoint connects to SCTP's multi-homing. In effect an illegitimate endpoint connects to
a server and "camps upon" or holds up a valid peers address. This is a server and "camps upon" or holds up a valid peers address. This is
done to prevent the legitimate peer from communicating with the done to prevent the legitimate peer from communicating with the
server. server.
2.1. Attack details 2.1. Attack details
skipping to change at page 4, line 30 skipping to change at page 4, line 31
This particular attack was discussed in detail on the SCTP This particular attack was discussed in detail on the SCTP
implementors list in March of 2003. Out of that discussion changes implementors list in March of 2003. Out of that discussion changes
were made in the BSD implementation that are now present in the were made in the BSD implementation that are now present in the
SCTP-IG. In closely examination this attack depends on a number of SCTP-IG. In closely examination this attack depends on a number of
specific things to occur. specific things to occur.
1) The attacker must setup the association before the victim and must 1) The attacker must setup the association before the victim and must
correctly guess the port number that the victim will use. If the correctly guess the port number that the victim will use. If the
victim uses any other port number the attack will fail. victim uses any other port number the attack will fail.
2) SCTP's existing HEARTBEAT mechanism as defined in RFC2960 [2] will 2) SCTP's existing HEARTBEAT mechanism as defined in RFC2960
eventually catch this situation and abort the evil attackers [RFC2960] will eventually catch this situation and abort the evil
association. This may take several seconds based on default attackers association. This may take several seconds based on
HEARTBEAT timers but the attacker himself will lose any default HEARTBEAT timers but the attacker himself will lose any
association. association.
3) If the victim is either not multi-homed, or the address set that 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 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 if the attacker had included IP-D in its INIT as well), then the
client's INIT message would restart the attackers association client's INIT message would restart the attackers association
destroying it. destroying it.
2.3. Counter measure 2.3. Counter measure
skipping to change at page 6, line 48 skipping to change at page 6, line 50
finally retransmits the ASCONF (from step 2). finally retransmits the ASCONF (from step 2).
3.3. Counter measure 3.3. Counter measure
The latest SCTP-IG adds a new counter measure to this threat. It is The latest SCTP-IG adds a new counter measure to this threat. It is
now required that Tie-Tags in the State-Cookie parameter not be the now required that Tie-Tags in the State-Cookie parameter not be the
actual tags. Instead a new set of two 32 bit nonce must be used to actual tags. Instead a new set of two 32 bit nonce must be used to
represent the real tags within the association. This prevents the represent the real tags within the association. This prevents the
attacker from acquiring the real tags and thus prevents this attack. attacker from acquiring the real tags and thus prevents this attack.
Furthermore the use of the ADD-IP extensions requires the use of the Furthermore the use of the ADD-IP extensions requires the use of the
authentication mechanism defined in SCTP-AUTH [3]. This requires the authentication mechanism defined in SCTP-AUTH
attacker to be able to capture the traffic during the association [I-D.tuexen-sctp-auth-chunk]. This requires the attacker to be able
setup. If in addition an end-point pair shared key is used, to capture the traffic during the association setup. If in addition
capturing or intercepting these setup messages does not enable the an end-point pair shared key is used, capturing or intercepting these
attacker to hijack the association. setup messages does not enable the attacker to hijack the
association.
4. Association hijacking 2 4. Association hijacking 2
Association hijacking is the ability of some other user to assume the Association hijacking is the ability of some other user to assume the
session created by another endpoint. In cases where an attacker can session created by another endpoint. In cases where an attacker can
take over an IP-address he can easily restart the association. If take over an IP-address he can easily restart the association. If
the peer does not pay attention to the restart notification the the peer does not pay attention to the restart notification the
attacker has taken over the association. attacker has taken over the association.
4.1. Attack details 4.1. Attack details
skipping to change at page 11, line 49 skipping to change at page 12, line 7
This attack is a byte and not a packet amplification attack and This attack is a byte and not a packet amplification attack and
without protocol changes hard to avoid. without protocol changes hard to avoid.
9.3. Counter measure 9.3. Counter measure
A server should be implemented in a way that the generated INIT-ACK A server should be implemented in a way that the generated INIT-ACK
chunks are as small as possible. chunks are as small as possible.
10. References 10. References
[1] Aura, T., Nikander, P., and G. Camarillo, "Effects of Mobility [effects] Aura, T., Nikander, P., and G. Camarillo, "Effects of
and Multihoming on Transport-Layer Security", December 2003. Mobility and Multihoming on Transport-Layer Security",
December 2003.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
"Stream Control Transmission Protocol", RFC 2960, October 2000. Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[3] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, [I-D.tuexen-sctp-auth-chunk]
"Authenticated Chunks for Stream Control Transmission Protocol Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
(SCTP)", draft-tuexen-sctp-auth-chunk-03 (work in progress), "Authenticated Chunks for Stream Control Transmission
February 2005. Protocol (SCTP)", draft-tuexen-sctp-auth-chunk-03 (work in
progress), February 2005.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
4785 Forest Drive 4785 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
skipping to change at page 14, line 5 skipping to change at page 13, line 5
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 14, line 29 skipping to change at page 13, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 18 change blocks. 
58 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/