draft-ietf-tsvwg-sctpthreat-02.txt   draft-ietf-tsvwg-sctpthreat-03.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: April 19, 2007 Muenster Univ. of Applied Sciences Expires: October 7, 2007 Muenster Univ. of Applied Sciences
G. Camarillo G. Camarillo
Ericsson Ericsson
October 16, 2006 April 5, 2007
Security Attacks Found Against SCTP and Current Countermeasures Security Attacks Found Against SCTP and Current Countermeasures
draft-ietf-tsvwg-sctpthreat-02.txt draft-ietf-tsvwg-sctpthreat-03.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 April 19, 2007. This Internet-Draft will expire on October 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Stream Control Transmission Protocol defined in RFC 2960 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 their 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 RFC 4460. 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
skipping to change at page 4, line 17 skipping to change at page 4, line 17
Next the victim sends in an INIT message listing its two valid 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 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 message with possibly an error code indicating that a new address was
added in its attempt to setup an existing association (a restart with added in its attempt to setup an existing association (a restart with
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. 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 were made in the BSD implementation that are now present in the
SCTP-IG [3]. In closely examination this attack depends on a number SCTP-IG [3]. In closely examination this attack depends on a number
of 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.
skipping to change at page 4, line 41 skipping to change at page 4, line 41
association. This may take several seconds based on default association. This may take several seconds based on 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. Mitigation option
SCTP-IG [3] adds a new set of requirements to better counter this SCTP-IG [3] adds a new set of requirements to better counter this
attack. In particular the HEARTBEAT mechanism was modified so that attack. In particular the HEARTBEAT mechanism was modified so that
addresses unknown to an endpoint (i.e. presented in an INIT with no addresses unknown to an endpoint (i.e. presented in an INIT with no
pre-knowledge given by the application) enter a new state called pre-knowledge given by the application) enter a new state called
"UNCONFIRMED". During the time that any address is UNCONFIRMED and "UNCONFIRMED". During the time that any address is UNCONFIRMED and
yet considered available, heartbeating will be done on those yet considered available, heartbeating will be done on those
UNCONFIRMED addresses at an accelerated rate. This will lessen the UNCONFIRMED addresses at an accelerated rate. This will lessen the
time that an attacker can "camp" on an address. In particular the time that an attacker can "camp" on an address. In particular the
rate of heartbeats to UNCONFIRMED addresses is done every RTO. Along rate of heartbeats to UNCONFIRMED addresses is done every RTO. Along
with this expanded rate of heartbeating, a new 64 bit random nonce is with this expanded rate of heartbeating, a new 64 bit random nonce is
required to be inside HEARTBEATs to UNCONFIRMED addresses. In the required to be inside HEARTBEATs to UNCONFIRMED addresses. In the
HEARTBEAT-ACK the random nonce MUST match the value sent in the HEARTBEAT-ACK the random nonce must match the value sent in the
HEARTBEAT before an address can leave the UNCONFIRMED state. This HEARTBEAT before an address can leave the UNCONFIRMED state. This
will prevent an attacker from generating false HEARTBEAT-ACK's with will prevent an attacker from generating false HEARTBEAT-ACKs with
the victims source address(es). In addition, clients which do not the victims source address(es). In addition, clients which do not
need to use a specific port number should choose their port numbers need to use a specific port number should choose their port numbers
on a random base. This makes it hard for an attacker to guess that on a random base. This makes it 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 [5] extension to SCTP a However with the addition of the ADD-IP [6] extension to SCTP a
endpoint that is NOT a man-in-the-middle may be able to assume endpoint that is NOT a man-in-the-middle may be able to assume
another 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.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
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. 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 [5] extension. 1) Both endpoints must support the ADD-IP [6] extension.
2) One of the endpoints must be using the ADD-IP [5] extension for 2) One of the endpoints must be using the ADD-IP [6] 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. Mitigation option
SCTP-IG [3] adds a new counter measure to this threat. It is now SCTP-IG [3] adds a new counter measure to this threat. It is 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 nonces 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 [5] extensions requires the use of Furthermore the use of the ADD-IP [6] extensions requires the use of
the authentication mechanism defined in SCTP-AUTH [4]. This requires the authentication mechanism defined in SCTP-AUTH [5]. This requires
the attacker to be able to capture the traffic during the association the attacker to be able to capture the traffic during the association
setup. If in addition an end-point pair shared key is used, setup. If in addition an end-point pair shared key is used,
capturing or intercepting these setup messages does not enable the capturing or intercepting these setup messages does not enable the
attacker to hijack the association. 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
skipping to change at page 7, line 26 skipping to change at page 7, line 26
Assume that an endpoint E1 having an IP-address A has an SCTP Assume that an endpoint E1 having an IP-address A has an SCTP
association with endpoint E2. After the attacker has taken over the association with endpoint E2. After the attacker has taken over the
IP-address A he waits for a packet from E2. After reception of the IP-address A he waits for a packet from E2. After reception of the
packet the attacker can perform a full four way handshake using the packet the attacker can perform a full four way handshake using the
the IP-addresses and port numbers from the received packet. E2 will the IP-addresses and port numbers from the received packet. E2 will
consider this as a restart of the association. If and only if the consider this as a restart of the association. If and only if the
SCTP user of E2 does not process the restart notification the user SCTP user of E2 does not process the restart notification the user
will not recognize that that association just restarted. From his will not recognize that that association just restarted. From his
perspective the association has been hijacked. perspective the association has been hijacked.
4.2. Errata 4.2. Analysis
This attack depends on a number of circumstances: This attack depends on a number of circumstances:
1) The IP address must be acquired in such a way as to make the evil 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 endpoint the owner of that IP address as far as the network or
local lan is concerned. local LAN is concerned.
2) The attacker must receive a packet belonging to the association or 2) The attacker must receive a packet belonging to the association or
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. Counter measure 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. Note that other IP protocols may notifications provided by SCTP. Note that other IP protocols may
also be effected by this attack. 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
skipping to change at page 8, line 25 skipping to change at page 8, line 25
large data transfer. After making the request the attacker does not large data transfer. After making the request the attacker does not
acknowledge data sent to it. This then causes the server to re- 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. transmit the data to the alternate address i.e. that of the victim.
After waiting an appropriate time period the attacker acknowledges After waiting an appropriate time period the attacker acknowledges
the data for the victim. At some point the attackers address is the data for the victim. At some point the attackers address is
considered unreachable since only data sent to the victims address is considered unreachable since only data sent to the victims address is
acknowledged. At this point the attacker can send strategic acknowledged. At this point the attacker can send strategic
acknowledgments so that the server continues to send data to the acknowledgments so that the server continues to send data to the
victim. victim.
5.2. Errata 5.2. Analysis
This attack depends on a number of circumstances: This attack depends on a number of circumstances:
1) The victim must NOT support SCTP, otherwise it would respond with 1) The victim must NOT support SCTP, otherwise it would respond with
an OOTB abort. an OOTB abort.
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. Mitigation option
SCTP-IG [3] makes two changes to prevent this attack. First it SCTP-IG [3] makes two changes to prevent this attack. First 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 SCTP-IG [3] is the requirement that no The second change made in SCTP-IG [3] is the requirement that no
skipping to change at page 9, line 32 skipping to change at page 9, line 32
Optionally it request a long cookie life time. Upon reception of the Optionally it request a long cookie life time. Upon reception of the
INIT-ACK it stores the cookie and sends it back to the other INIT-ACK it stores the cookie and sends it back to the other
endpoint. When the other endpoint receives the COOKIE it will send endpoint. When the other endpoint receives the COOKIE it will send
back a COOKIE-ACK to the attacker and up to Max.Burst HEARTBEATS to back a COOKIE-ACK to the attacker and up to Max.Burst HEARTBEATS to
the victim('s) (to confirm addresses). The victim responds with the victim('s) (to confirm addresses). The victim responds with
ABORTs or ICMP messages resulting in the removal of the TCB at the ABORTs or ICMP messages resulting in the removal of the TCB at the
other endpoint. The attacker can now resend the stored cookie as other endpoint. The attacker can now resend the stored cookie as
long as it is valid and this will again result in up to Max.Burst long as it is valid and this will again result in up to Max.Burst
HEARTBEATs sent to the victim('s). HEARTBEATs sent to the victim('s).
6.2. Errata 6.2. Analysis
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 Max.Burst. Also the shorter the the victim and of the end point 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. Counter measure 6.3. Mitigation option
To limit the effectiveness of this attack and end point should To limit the effectiveness of this attack and end 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 Max.Burst parameter values than recommended or 2) not use larger Max.Burst parameter values than recommended or
alternatively only send one CONFIRMATION Heartbeat per RTT. Note alternatively only send one CONFIRMATION Heartbeat per RTT. Note
that an endpoint may decide to send only one Heartbeat per RTT that an endpoint may decide to send only one Heartbeat per RTT
instead of the maximum (i.e. Max.Burst). An endpoint that instead of the maximum (i.e. Max.Burst). An endpoint that
chooses this approach will however slow down detection of chooses this approach will however slow down detection of
skipping to change at page 10, line 22 skipping to change at page 10, line 22
different endpoint. different endpoint.
7.1. Attack details 7.1. Attack details
The attacker sends an INIT sourced from port 'X' and directed towards The attacker sends an INIT sourced from port 'X' and directed towards
port 'Y'. When the INIT-ACK is returned the attacker sends the port 'Y'. When the INIT-ACK is returned the attacker sends the
COOKIE-ECHO chunk and either places a different destination or source 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 then set's up port in the SCTP common header i.e. X+1 or Y+1. This then set's up
the association with possibly other endpoints. the association with possibly other endpoints.
7.2. Errata 7.2. Analysis
This attack depends on the failure of an SCTP implementation to store This attack depends on the failure of an SCTP implementation to store
and verify the ports within the COOKIE structure. and verify the ports within the COOKIE structure.
7.3. Counter measure 7.3. Mitigation option
This attack is easily defeated by an implementation including the This attack is easily defeated by an implementation including the
ports of both the source and destination within the COOKIE. When the ports of both the source and destination within the COOKIE. When the
COOKIE is returned if the source and destination ports do not match COOKIE is returned if the source and destination ports do not match
those within the COOKIE chunk, the SCTP implementation silently those within the COOKIE chunk, the SCTP implementation silently
discards the invalid COOKIE. discards the invalid COOKIE.
8. Bombing attack (amplification) 3 8. Bombing attack (amplification) 3
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
skipping to change at page 11, line 11 skipping to change at page 11, line 11
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 unknown 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. Analysis
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. Mitigation option
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 SCTP-IG The details of the required handling are described in the SCTP-IG
[3]. [3].
skipping to change at page 11, line 41 skipping to change at page 11, line 41
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. 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 [6]. the usage of the PAD parameter defined in SCTP-PAD [4].
9.3. Counter measure 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. Security Considerations 10. Security Considerations
This document is about security and there is nothing to be added to This document is about security and there is nothing to be added to
it in this section. it in this section.
11. IANA considerations 11. IANA considerations
skipping to change at page 12, line 27 skipping to change at page 12, line 27
and Multihoming on Transport-Layer Security", December 2003. and Multihoming on Transport-Layer Security", December 2003.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. [3] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M.
Tuexen, "Stream Control Transmission Protocol (SCTP) Tuexen, "Stream Control Transmission Protocol (SCTP)
Specification Errata and Issues", RFC 4460, April 2006. Specification Errata and Issues", RFC 4460, April 2006.
[4] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, [4] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
Parameter for the Stream Control Transmission Protocol (SCTP)",
RFC 4820, March 2007.
[5] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for Stream Control Transmission Protocol "Authenticated Chunks for Stream Control Transmission Protocol
(SCTP)", draft-ietf-tsvwg-sctp-auth (work in progress), (SCTP)", draft-ietf-tsvwg-sctp-auth (work in progress),
September 2006. September 2006.
[5] Stewart, R., "Stream Control Transmission Protocol (SCTP) [6] Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-15 (work in progress), June 2006. draft-ietf-tsvwg-addip-sctp-19 (work in progress), March 2007.
[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
skipping to change at page 14, line 7 skipping to change at page 14, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
 End of changes. 34 change blocks. 
42 lines changed or deleted 42 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/