draft-ietf-tsvwg-sctpthreat-01.txt   draft-ietf-tsvwg-sctpthreat-02.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational M. Tuexen Intended status: Informational M. Tuexen
Expires: February 8, 2007 Muenster Univ. of Applied Sciences Expires: April 19, 2007 Muenster Univ. of Applied Sciences
G. Camarillo G. Camarillo
Ericsson Ericsson
August 7, 2006 October 16, 2006
Security Attacks Found Against SCTP and Current Countermeasures Security Attacks Found Against SCTP and Current Countermeasures
draft-ietf-tsvwg-sctpthreat-01.txt draft-ietf-tsvwg-sctpthreat-02.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 February 8, 2007. This Internet-Draft will expire on April 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Stream Control Transmission Protocol RFC2960 [RFC2960] is a multi- Stream Control Transmission Protocol defined in RFC 2960 is a multi-
homed transport protocol. As such, unique security threats exists homed transport protocol. As such, unique security threats exists
that are addressed in various ways within the protocol itself. This that are addressed in various ways within the protocol itself. This
document attempts to detail the known security threats and there document attempts to detail the known security threats and their
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 RFC 4460. 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 Implementors guide.
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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
Stream Control Transmission Protocol RFC2960 [RFC2960] is a multi- Stream Control Transmission Protocol RFC2960 [2] is a multi-homed
homed transport protocol. As such, unique security threats exists transport protocol. As such, unique security threats exists that are
that are addressed in various ways within the protocol itself. This addressed in various ways within the protocol itself. This document
document attempts to detail the known security threats and there 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 [3]). It is hoped that this information
provide some useful background information for many of the newest will provide some useful background information for many of the
requirements spelled out in the SCTP-IG. newest requirements spelled out in the SCTP-IG [3].
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 SCTP-IG [3] are
the SCTP-IG are much indebted to the paper on potential SCTP security much indebted to the paper on potential SCTP security risks Effects
risks Effects [effects] by Aura, Nikander and Camarillo. Without [1] by Aura, Nikander and Camarillo. Without their work some of
there work some of these changes would remain undocumented and these changes would remain undocumented and potential 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 [effects] and detail what that were illustrated in Effects [1] and detail what preventative
preventative measures are now in place within the current SCTP measures are now in place within the current SCTP standards (if any).
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 24 skipping to change at page 4, line 22
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 that the attacker does not hold the address IP-C at some future
point. point.
2.2. Errata 2.2. Errata
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 [3]. In closely examination this attack depends on a number
specific things to occur. 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 in RFC2960 2) SCTP's existing HEARTBEAT mechanism as defined in RFC2960 [2] will
[RFC2960] will eventually catch this situation and abort the evil eventually catch this situation and abort the evil attackers
attackers association. This may take several seconds based on association. This may take several seconds based on default
default HEARTBEAT timers but the attacker himself will lose any 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
Version 10 of the SCTP-IG adds a new set of requirements to better SCTP-IG [3] adds a new set of requirements to better counter this
counter this attack. In particular the HEARTBEAT mechanism was attack. In particular the HEARTBEAT mechanism was modified so that
modified so that addresses unknown to an endpoint (i.e. presented in addresses unknown to an endpoint (i.e. presented in an INIT with no
an INIT with no pre-knowledge given by the application) enter a new pre-knowledge given by the application) enter a new state called
state called "UNCONFIRMED". During the time that any address is "UNCONFIRMED". During the time that any address is UNCONFIRMED and
UNCONFIRMED and yet considered available, heartbeating will be done yet considered available, heartbeating will be done on those
on those UNCONFIRMED addresses at an accelerated rate. This will UNCONFIRMED addresses at an accelerated rate. This will lessen the
lessen the time that an attacker can "camp" on an address. In time that an attacker can "camp" on an address. In particular the
particular the rate of heartbeats to UNCONFIRMED addresses is done rate of heartbeats to UNCONFIRMED addresses is done every RTO. Along
every RTO. Along with this expanded rate of heartbeating, a new 64 with this expanded rate of heartbeating, a new 64 bit random nonce is
bit random nonce is required to be inside HEARTBEATs to UNCONFIRMED required to be inside HEARTBEATs to UNCONFIRMED addresses. In the
addresses. In the HEARTBEAT-ACK the random nonce MUST match the HEARTBEAT-ACK the random nonce MUST match the value sent in the
value sent in the HEARTBEAT before an address can leave the HEARTBEAT before an address can leave the UNCONFIRMED state. This
UNCONFIRMED state. This will prevent an attacker from generating will prevent an attacker from generating false HEARTBEAT-ACK's with
false HEARTBEAT-ACK's with the victims source address(es). In the victims source address(es). In addition, clients which do not
addition, clients which do not need to use a specific port number need to use a specific port number should choose their port numbers
should choose their port numbers on a random base. This makes it on a random base. This makes it hard for an attacker to guess that
hard for an attacker to guess that number. 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 extension to SCTP a endpoint However with the addition of the ADD-IP [5] extension to SCTP a
that is NOT a man-in-the-middle may be able to assume another endpoint that is NOT a man-in-the-middle may be able to assume
endpoints association. 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 4 skipping to change at page 5, line 46
| |
|-DHCP-new-net------>| |-DHCP-new-net------>|
3 |<---Assign (IP-A) 3 |<---Assign (IP-A)
| |
4 |<------------Tag:X-DATA()------------------ 4 |<------------Tag:X-DATA()------------------
| |
|-------------INIT()------------------------> |-------------INIT()------------------------>
5 |<------------INIT-ACK()--------------------- 5 |<------------INIT-ACK()---------------------
| |
6 |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------> 6 |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------>
Figure 2: Association Hijack via DHCP
Figure 2: Association Hijack via DHCP
At point 1, our valid client releases the IP address IP-A. It 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 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 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 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 DHCP's peer is no longer at IP-A. Now at point 3 a new "evil" peer DHCP's
an address and happens to get the re-assigned address IP-A. Our an address and happens to get the re-assigned address IP-A. Our
Peer-Server sends a chunk of DATA at point 4. This reveals to the 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 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. 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 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 would of course hold tie-tags which would list both sets of tags
which could then be used at point 6 to add in any other IP addresses which 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. that the owner of IP-A holds and thus acquire the association.
3.2. Errata 3.2. Errata
This attack depends on a number of events: This attack depends on a number of events:
1) Both endpoints must support the ADD-IP extension. 1) Both endpoints must support the ADD-IP [5] extension.
2) One of the endpoints must be using the ADD-IP extension for 2) One of the endpoints must be using the ADD-IP [5] extension for
mobility. 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. Counter measure 3.3. Counter measure
The latest SCTP-IG adds a new counter measure to this threat. It is SCTP-IG [3] adds a new counter measure to this threat. It is now
now required that Tie-Tags in the State-Cookie parameter not be the 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 nonces 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 [5] extensions requires the use of
authentication mechanism defined in SCTP-AUTH the authentication mechanism defined in SCTP-AUTH [4]. This requires
[I-D.tuexen-sctp-auth-chunk]. This requires the attacker to be able the attacker to be able to capture the traffic during the association
to capture the traffic during the association setup. If in addition setup. If in addition an end-point pair shared key is used,
an end-point pair shared key is used, capturing or intercepting these capturing or intercepting these setup messages does not enable the
setup messages does not enable the attacker to hijack the attacker to hijack the association.
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 8, line 42 skipping to change at page 8, line 42
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. Counter measure 5.3. Counter measure
The current SCTP-IG makes two changes to prevent this attack. First SCTP-IG [3] makes two changes to prevent this attack. First it
it details out proper handling of ICMP messages. With SCTP the ICMP details out proper handling of ICMP messages. With SCTP the ICMP
messages provide valuable clues to the SCTP stack that can be 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 the newest SCTP-IG is the requirement that The second change made in SCTP-IG [3] is the requirement that no
no address that is not CONFIRMED is allowed to have DATA chunks sent address that is not CONFIRMED is allowed to have DATA chunks sent to
to it. This prevents the switch-over to the alternate address from it. This prevents the switch-over to the alternate address from
occurring even when ICMP messages are lost in the network and 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. other then the attacker itself.
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.
6. Bombing attack (amplification) 2 6. Bombing attack (amplification) 2
skipping to change at page 11, line 6 skipping to change at page 11, line 6
The attacker sends a packet to an SCTP endpoint which requires the The attacker sends a packet to an SCTP endpoint which requires the
sending of multiple chunks. If the SCTP endpoint does not support sending of multiple chunks. If the SCTP endpoint does not support
bundling on the sending side it might send each chunk per packet. 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 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 address as the sources address or it can be considered an attack
against the network. Since the chunks which need to be send in against the network. Since the chunks which need to be send in
response to the received packet may not fit into one packet an response to the received packet may not fit into one packet an
endpoint supporting bundling on the sending side might send multiple endpoint supporting bundling on the sending side might send multiple
packets. packets.
Examples of these packets are packets containing a lot of unkown Examples of these packets are packets containing a lot of unknown
chunks which require an ERROR chunk to be sent, known chunks which chunks which require an ERROR chunk to be sent, known chunks which
initiate the sending of ERROR chunks, packets containing a lot of initiate the sending of ERROR chunks, packets containing a lot of
HEARTBEAT chunks and so on. HEARTBEAT chunks and so on.
8.2. Errata 8.2. Errata
This attack depends on the fact that the SCTP endpoint does not This attack depends on the fact that the SCTP endpoint does not
support bundling on the sending side or provides a bad implementation support bundling on the sending side or provides a bad implementation
of bundling on the sending side. of bundling on the sending side.
8.3. Counter measure 8.3. Counter measure
First of all, path verification must happen before sending other First of all, path verification must happen before sending other
chunks then HEARTBEATs for path verification. This makes sure that chunks then 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 IG. The details of the required handling are described in the SCTP-IG
[3].
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. Errata 9.2. Errata
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. A possible method would be
the usage of the PAD parameter defined in SCTP-PAD [6].
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. Security Considerations
[effects] Aura, T., Nikander, P., and G. Camarillo, "Effects of This document is about security and there is nothing to be added to
Mobility and Multihoming on Transport-Layer Security", it in this section.
December 2003.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 11. IANA considerations
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[I-D.tuexen-sctp-auth-chunk] There are no actions required from IANA.
Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for Stream Control Transmission 12. Informative References
Protocol (SCTP)", draft-tuexen-sctp-auth-chunk-03 (work in
progress), February 2005. [1] Aura, T., Nikander, P., and G. Camarillo, "Effects of Mobility
and Multihoming on Transport-Layer Security", December 2003.
[2] 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.
[3] 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.
[4] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for Stream Control Transmission Protocol
(SCTP)", draft-ietf-tsvwg-sctp-auth (work in progress),
September 2006.
[5] Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-15 (work in progress), June 2006.
[6] Tuexen, M., "Padding Chunk and Parameter for SCTP",
draft-ietf-tsvwg-sctp-padding-01 (work in progress),
September 2006.
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
 End of changes. 33 change blocks. 
86 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/