draft-ietf-tsvwg-sctpthreat-04.txt   draft-ietf-tsvwg-sctpthreat-05.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: December 11, 2007 M. Tuexen Expires: December 15, 2007 M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
G. Camarillo G. Camarillo
Ericsson Ericsson
June 9, 2007 June 13, 2007
Security Attacks Found Against SCTP and Current Countermeasures Security Attacks Found Against SCTP and Current Countermeasures
draft-ietf-tsvwg-sctpthreat-04.txt draft-ietf-tsvwg-sctpthreat-05.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 December 11, 2007. This Internet-Draft will expire on December 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes certain security threats to SCTP. It also This document describes certain security threats to SCTP. It also
describes ways to mitigate these threats, in particular by using describes ways to mitigate these threats, in particular by using
techniques from the SCTP Specification Errata and Issues memo (RFC techniques from the SCTP Specification Errata and Issues memo (RFC
4460). These techniques are included in RFC 2960bis, which obsoletes 4460). These techniques are included in RFC 4960, which obsoletes
RFC 2960. It is hoped that this information will provide some useful RFC 2960. It is hoped that this information will provide some useful
background information for many of the newest requirements spelled background information for many of the newest requirements spelled
out in the SCTP Specification Errata and Issues and included in RFC out in the SCTP Specification Errata and Issues and included in RFC
2960bis. 4960.
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 . . . . . . . . . . . . . . . 8 5. Bombing attack (amplification) 1 . . . . . . . . . . . . . . . 8
6. Bombing attack (amplification) 2 . . . . . . . . . . . . . . . 9 6. Bombing attack (amplification) 2 . . . . . . . . . . . . . . . 10
7. Association redirection . . . . . . . . . . . . . . . . . . . 10 7. Association redirection . . . . . . . . . . . . . . . . . . . 11
8. Bombing attack (amplification) 3 . . . . . . . . . . . . . . . 11 8. Bombing attack (amplification) 3 . . . . . . . . . . . . . . . 11
9. Bombing attack (amplification) 4 . . . . . . . . . . . . . . . 12 9. Bombing attack (amplification) 4 . . . . . . . . . . . . . . . 12
10. Bombing attack (amplification) 5 . . . . . . . . . . . . . . . 12 10. Bombing attack (amplification) 5 . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
Stream Control Transmission Protocol originally defined in RFC2960 Stream Control Transmission Protocol originally defined in [RFC2960]
[1] is a multi-homed transport protocol. As such, unique security is a multi-homed transport protocol. As such, unique security
threats exists that are addressed in various ways within the protocol threats exists that are addressed in various ways within the protocol
itself. This document describes certain security threats to SCTP. itself. This document describes certain security threats to SCTP.
It also describes ways to mitigate these threats, in particular by It also describes ways to mitigate these threats, in particular by
using techniques from the SCTP Specification Errata and Issues memo using techniques from the SCTP Specification Errata and Issues memo
(RFC4460 [2]). These techniques are included in RFC2960bis [3], ([RFC4460]). These techniques are included in
which obsoletes RFC2960 [1]. It is hoped that this information will [I-D.ietf-tsvwg-2960bis], which obsoletes [RFC2960]. It is hoped
provide some useful background information for many of the newest that this information will provide some useful background information
requirements spelled out in the SCTP-errata [2] and included in RFC for many of the newest requirements spelled out in the [RFC4460] and
2960bis [3]. included in [I-D.ietf-tsvwg-2960bis].
This work and some of the changes that went into the SCTP-errata [2] This work and some of the changes that went into the [RFC4460] and
and RFC 2960bis [3] are much indebted to the paper on potential SCTP [I-D.ietf-tsvwg-2960bis] are much indebted to the paper on potential
security risks Effects [7] by Aura, Nikander and Camarillo. Without SCTP security risks Effects [effects] by Aura, Nikander and
their work some of these changes would remain undocumented and Camarillo. Without their work some of these changes would remain
potential threats. undocumented and 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 [7] 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 26 skipping to change at page 4, line 27
new addresses). At this point 'Client-Victim' is now prevented from new addresses). At this point 'Client-Victim' is now prevented from
setting up an association with the server until the server realizes 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 that the attacker does not hold the address IP-C at some future point
by using a HEARTBEAT based mechanism. See the mitigation option by using a HEARTBEAT based mechanism. See the mitigation option
subsection of this section. subsection of this section.
2.2. Analysis 2.2. Analysis
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 RFC were made in the BSD implementation that are now present in the
2960bis [3]. In close examination, this attack depends on a number [I-D.ietf-tsvwg-2960bis]. In close examination, this attack depends
of specific things to occur. on a number of 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 already in RFC2960 2) SCTP's existing HEARTBEAT mechanism as defined already in
[1] will eventually catch this situation and abort the evil [RFC2960] will eventually catch this situation and abort the evil
attackers association. This may take several seconds based on attackers association. This may take several seconds based on
default 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 initiate an association between the client's INIT message would initiate an association between the
client and the server while destroying the association between the client and the server while destroying the association between the
attacker and the server. From the servers' perspective this is a attacker and the server. From the servers' perspective this is a
restart of the association. restart of the association.
2.3. Mitigation option 2.3. Mitigation option
RFC 2960bis [3] adds a new set of requirements to better counter this [I-D.ietf-tsvwg-2960bis] adds a new set of requirements to better
attack. In particular the HEARTBEAT mechanism was modified so that counter this attack. In particular the HEARTBEAT mechanism was
addresses unknown to an endpoint (i.e. presented in an INIT with no modified so that addresses unknown to an endpoint (i.e. presented in
pre-knowledge given by the application) enter a new state called an INIT with no pre-knowledge given by the application) enter a new
"UNCONFIRMED". During the time that any address is UNCONFIRMED and state called "UNCONFIRMED". During the time that any address is
yet considered available, heartbeating will be done on those UNCONFIRMED and yet considered available, heartbeating will be done
UNCONFIRMED addresses at an accelerated rate. This will lessen the on those UNCONFIRMED addresses at an accelerated rate. This will
time that an attacker can "camp" on an address. In particular the lessen the time that an attacker can "camp" on an address. In
rate of heartbeats to UNCONFIRMED addresses is done every RTO. Along particular the rate of heartbeats to UNCONFIRMED addresses is done
with this expanded rate of heartbeating, a new 64 bit random nonce is every RTO. Along with this expanded rate of heartbeating, a new 64
required to be inside HEARTBEATs to UNCONFIRMED addresses. In the bit random nonce is required to be inside HEARTBEATs to UNCONFIRMED
HEARTBEAT-ACK the random nonce must match the value sent in the addresses. In the HEARTBEAT-ACK the random nonce must match the
HEARTBEAT before an address can leave the UNCONFIRMED state. This value sent in the HEARTBEAT before an address can leave the
will prevent an attacker from generating false HEARTBEAT-ACKs with UNCONFIRMED state. This will prevent an attacker from generating
the victims source address(es). In addition, clients which do not false HEARTBEAT-ACKs with the victims source address(es). In
need to use a specific port number should choose their port numbers addition, clients which do not need to use a specific port number
on a random base. This makes it hard for an attacker to guess that should choose their port numbers on a random base. This makes it
number. hard for an attacker to guess that number.
3. Association hijacking 1 3. Association hijacking 1
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 of a true man-in-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. middle only a strong end-to-end security model can prevent this.
However with the addition of the ADD-IP [6] extension to SCTP an However with the addition of the [I-D.ietf-tsvwg-addip-sctp]
endpoint that is NOT a man-in-the-middle may be able to assume extension to SCTP an endpoint that is NOT a man-in-the-middle may be
another endpoints association. able to assume another endpoints association.
3.1. Attack details 3.1. Attack details
The attack is made possible by any mechanism that lets an endpoint 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 acquire some other IP address that was recently in use by an SCTP
endpoint. For example in a mobile network DHCP may be in use with endpoint. For example in a mobile network DHCP may be in use with
short IP address lifetimes to reassign IP addresses to migrant hosts. short IP address lifetimes to reassign IP addresses to migrant hosts.
IP-A DHCP-Server's Peer-Server IP-A DHCP-Server's Peer-Server
| |
skipping to change at page 6, line 46 skipping to change at page 6, line 46
that the owner of IP-A holds and thus acquire the association. that the owner of IP-A holds and thus acquire the association.
It should be noted that this attack is possible in general whenever 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 the attacker is able to send packets with source address IP-A and
receive packets with destination address IP-A. receive packets with destination address IP-A.
3.2. Analysis 3.2. Analysis
This attack depends on a number of events: This attack depends on a number of events:
1) Both endpoints must support the ADD-IP [6] extension. 1) Both endpoints must support the [I-D.ietf-tsvwg-addip-sctp]
extension.
2) One of the endpoints must be using the ADD-IP [6] extension for 2) One of the endpoints must be using the [I-D.ietf-tsvwg-addip-sctp]
mobility. extension for mobility.
3) The IP address must be acquired in such a way as to make the 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 endpoint the owner of that IP address as far as the network is
concerned. concerned.
4) The true peer must not get the ASCONF packet that deletes IP-A and 4) The true peer must not get the ASCONF packet that deletes IP-A and
adds its new address to the peer before the new "evil" peer gets adds its new address to the peer before the new "evil" peer gets
control of the association. control of the association.
5) The new "evil" peer must have an alternative address besides IP-A 5) The new "evil" peer must have an alternative address besides IP-A
that it can add to the association so it can delete 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 preventing the real peer from re-acquiring the association when it
finally retransmits the ASCONF (from step 2). finally retransmits the ASCONF (from step 2).
3.3. Mitigation option 3.3. Mitigation option
RFC 2960bis [3] adds a new counter measure to this threat. It is now [I-D.ietf-tsvwg-2960bis] adds a new counter measure to this threat.
required that Tie-Tags in the State-Cookie parameter not be the It is now required that Tie-Tags in the State-Cookie parameter not be
actual tags. Instead a new pair of two 32 bit nonces must be used to the actual tags. Instead a new pair of two 32 bit nonces must be
represent the real tags within the association. This prevents the used to represent the real tags within the association. This
attacker from acquiring the real tags and thus prevents this attack. prevents the attacker from acquiring the real tags and thus prevents
Furthermore the use of the ADD-IP [6] extensions requires the use of this attack. Furthermore the use of the [I-D.ietf-tsvwg-addip-sctp]
the authentication mechanism defined in SCTP-AUTH [5]. This requires extensions requires the use of the authentication mechanism defined
the attacker to be able to capture the traffic during the association in [I-D.ietf-tsvwg-sctp-auth]. 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
send packets using the victims IP-address as a source address and can send packets using the victims IP-address as a source address and can
receive packets with the victims' address as destination address the receive packets with the victims' address as destination address the
attacker can easily restart the association. If the peer does not attacker can easily restart the association. If the peer does not
pay attention to the restart notification the attacker has taken over pay attention to the restart notification the attacker has taken over
the association. the association.
skipping to change at page 8, line 25 skipping to change at page 8, line 29
connection. connection.
3) The other endpoints user does not pay attention to restart 3) The other endpoints user does not pay attention to restart
notifications. notifications.
4.3. Mitigation option 4.3. Mitigation option
It is important to note that this attack is not based on a weakness 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 of the protocol but on the ignorance of the upper layer. This attack
is not possible if the upper layer processes the restart is not possible if the upper layer processes the restart
notifications provided by SCTP as described in section 10 of RFC2960 notifications provided by SCTP as described in section 10 of
[1] or RFC 2960bis [3]. Note that other IP protocols may also be [RFC2960] or [I-D.ietf-tsvwg-2960bis]. Note that other IP protocols
effected by this attack. may also be effected by this attack.
5. Bombing attack (amplification) 1 5. Bombing attack (amplification) 1
The bombing attack is a method to get a server to amplify packets to The bombing attack is a method to get a server to amplify packets to
an innocent victim. an innocent victim.
5.1. Attack details 5.1. Attack details
This attack is performed by setting up an association with a peer and 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. listing the victims IP address in the INIT's list of addresses.
skipping to change at page 9, line 23 skipping to change at page 9, line 27
2) The attacker must time its sending of acknowledgments correctly in 2) The attacker must time its sending of acknowledgments correctly in
order to get its address into the failed state and the victims order to get its address into the failed state and the victims
address as the only valid alternative. address as the only valid alternative.
3) The attacker must guess TSN values that are accepted by the 3) The attacker must guess TSN values that are accepted by the
receiver once the bombing begins since it must acknowledge packets receiver once the bombing begins since it must acknowledge packets
it no longer is seeing. it no longer is seeing.
5.3. Mitigation option 5.3. Mitigation option
RFC 2960bis [3] makes two changes to prevent this attack. First it [I-D.ietf-tsvwg-2960bis] makes two changes to prevent this attack.
details out proper handling of ICMP messages. With SCTP the ICMP First it details out proper handling of ICMP messages. With SCTP the
messages provide valuable clues to the SCTP stack that can be ICMP messages provide valuable clues to the SCTP stack that can be
verified with the tags for authenticity. Proper handling of an ICMP verified with the tags for authenticity. Proper handling of an ICMP
protocol unreachable (or equivalent) would cause the association protocol unreachable (or equivalent) would cause the association
setup by the attacker to be immediately failed upon the first setup by the attacker to be immediately failed upon the first
retransmission to the victims address. retransmission to the victims address.
The second change made in RFC 2960bis [3] is the requirement that no The second change made in [I-D.ietf-tsvwg-2960bis] is the requirement
address that is not CONFIRMED is allowed to have DATA chunks sent to that no address that is not CONFIRMED is allowed to have DATA chunks
it. This prevents the switch-over to the alternate address from sent to it. This prevents the switch-over to the alternate address
occurring even when ICMP messages are lost in the network and from occurring even when ICMP messages are lost in the network and
prevents any DATA chunks from being sent to any other destination prevents any DATA chunks from being sent to any other destination
other then the attacker itself. This also prevents the alternative 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 way of using ADD-IP to add the new address and make it the primary
address. address.
An SCTP implementation should abort the association if it receives a An SCTP implementation should abort the association if it receives a
SACK acknowledging a TSN which has not been sent. This makes TSN SACK acknowledging a TSN which has not been sent. This makes TSN
guessing for the attacker quite hard because if the attacker guessing for the attacker quite hard because if the attacker
acknowledges one TSN too fast the association will be aborted. acknowledges one TSN too fast the association will be aborted.
skipping to change at page 10, line 31 skipping to change at page 10, line 36
The multiplication factor is limited by the number of addresses of The multiplication factor is limited by the number of addresses of
the victim and of the end point HB.Max.Burst. Also the shorter the the victim and of the end point HB.Max.Burst. Also the shorter the
cookie life time is, the earlier the attacker has to go through the cookie life time is, the earlier the attacker has to go through the
initial stage of sending an INIT instead of the just sending the initial stage of sending an INIT instead of the just sending the
COOKIE. It should also be noted that the attack is more effective if COOKIE. It should also be noted that the attack is more effective if
large HEARTBEATs are used for path confirmation. large HEARTBEATs are used for path confirmation.
6.3. Mitigation option 6.3. Mitigation option
To limit the effectiveness of this attack the new parameter To limit the effectiveness of this attack the new parameter
HB.Max.Burst was introduced in RFC 2960bis [3] and an end point HB.Max.Burst was introduced in [I-D.ietf-tsvwg-2960bis] and an end
should: point should:
1) not allow very large cookie lifetimes, even if they are requested. 1) not allow very large cookie lifetimes, even if they are requested.
2) not use larger HB.Max.Burst parameter values than recommended. 2) not use larger HB.Max.Burst parameter values than recommended.
Note that an endpoint may decide to send only one Heartbeat per 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 RTT instead of the maximum (i.e. HB.Max.Burst). An endpoint that
chooses this approach will however slow down detection of chooses this approach will however slow down detection of
endpoints camping on valid addresses. endpoints camping on valid addresses.
3) not use large HEARTBEATs for path confirmation. 3) not use large HEARTBEATs for path confirmation.
skipping to change at page 12, line 15 skipping to change at page 12, line 20
8.3. Mitigation option 8.3. Mitigation option
First of all, path verification must happen before sending other First of all, path verification must happen before sending other
chunks than HEARTBEATs for path verification. This makes sure that chunks than HEARTBEATs for path verification. This makes sure that
the above attack can not be used against other hosts. To avoid the the above attack can not be used against other hosts. To avoid the
attack, an SCTP endpoint should implement bundling on the sending attack, an SCTP endpoint should implement bundling on the sending
side and should not send multiple packets in response. If the SCTP side and should not send multiple packets in response. If the SCTP
endpoint does not support bundling on the sending side it should not 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. send in general more than one packet in response to a received one.
The details of the required handling are described in the RFC 2960bis The details of the required handling are described in the
[3]. [I-D.ietf-tsvwg-2960bis].
9. Bombing attack (amplification) 4 9. Bombing attack (amplification) 4
This attack allows an attacker to use an SCTP server to send a larger This attack allows an attacker to use an SCTP server to send a larger
packets to a victim than it sent to the SCTP server. packets to a victim than it sent to the SCTP server.
9.1. Attack details 9.1. Attack details
The attacker sends packets using the victim's address as the source The attacker sends packets using the victim's address as the source
address containing an INIT chunk to an SCTP Server. The server then address containing an INIT chunk to an SCTP Server. The server then
sends an packet containing an INIT-ACK chunk to the victim, which is sends an packet containing an INIT-ACK chunk to the victim, which is
most likely larger than the packet containing the INIT. most likely larger than the packet containing the INIT.
9.2. Analysis 9.2. Analysis
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. A possible method would be without protocol changes hard to avoid. A possible method would be
the usage of the PAD parameter defined in SCTP-PAD [4]. the usage of the PAD parameter defined in [RFC4820].
9.3. Mitigation option 9.3. Mitigation option
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. Bombing attack (amplification) 5 10. Bombing attack (amplification) 5
This attack allows an attacker to use an SCTP endpoint to send a This attack allows an attacker to use an SCTP endpoint to send a
large number of packets in response to one packet. large number of packets in response to one packet.
skipping to change at page 13, line 36 skipping to change at page 13, line 41
it in this section. it in this section.
12. IANA considerations 12. IANA considerations
There are no actions required from IANA. There are no actions required from IANA.
13. References 13. References
13.1. Normative References 13.1. Normative References
[1] 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.
[2] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and
Tuexen, "Stream Control Transmission Protocol (SCTP) M. Tuexen, "Stream Control Transmission Protocol (SCTP)
Specification Errata and Issues", RFC 4460, April 2006. Specification Errata and Issues", RFC 4460, April 2006.
[3] Stewart, R., "Stream Control Transmission Protocol", [I-D.ietf-tsvwg-2960bis]
draft-ietf-tsvwg-2960bis-04 (work in progress), April 2007. Stewart, R., "Stream Control Transmission Protocol",
draft-ietf-tsvwg-2960bis-05 (work in progress), June 2007.
[4] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
Parameter for the Stream Control Transmission Protocol (SCTP)", Parameter for the Stream Control Transmission Protocol
RFC 4820, March 2007. (SCTP)", RFC 4820, March 2007.
[5] Tuexen, M., "Authenticated Chunks for Stream Control [I-D.ietf-tsvwg-sctp-auth]
Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctp-auth-08 Tuexen, M., "Authenticated Chunks for Stream Control
(work in progress), February 2007. Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctp-auth-08 (work in progress),
February 2007.
[6] Stewart, R., "Stream Control Transmission Protocol (SCTP) [I-D.ietf-tsvwg-addip-sctp]
Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-20 (work in progress), April 2007. draft-ietf-tsvwg-addip-sctp-21 (work in progress),
June 2007.
13.2. Informative References 13.2. Informative References
[7] 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", Security and Mobility and Multihoming on Transport-Layer Security",
Privacy 2004, IEEE Symposium , URL http:// Security and Privacy 2004, IEEE Symposium , URL http://
research.microsoft.com/users/tuomaura/Publications/ research.microsoft.com/users/tuomaura/Publications/
aura-nikander-camarillo-ssp04.pdf, May 2004. aura-nikander-camarillo-ssp04.pdf, May 2004.
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
 End of changes. 33 change blocks. 
96 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/