doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5062.txt b/doc/rfc/rfc5062.txt
new file mode 100644
index 0000000..2d3977d
--- /dev/null
+++ b/doc/rfc/rfc5062.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         R. Stewart
+Request for Comments: 5062                           Cisco Systems, Inc.
+Category: Informational                                        M. Tuexen
+                                      Muenster Univ. of Applied Sciences
+                                                            G. Camarillo
+                                                                Ericsson
+                                                          September 2007
+
+
+                    Security Attacks Found Against
+            the Stream Control Transmission Protocol (SCTP)
+                      and Current Countermeasures
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document describes certain security threats to SCTP.  It also
+   describes ways to mitigate these threats, in particular by using
+   techniques from the SCTP Specification Errata and Issues memo (RFC
+   4460).  These techniques are included in RFC 4960, which obsoletes
+   RFC 2960.  It is hoped that this information will provide some useful
+   background information for many of the newest requirements spelled
+   out in the SCTP Specification Errata and Issues and included in RFC
+   4960.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Informational                      [Page 1]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Address Camping or Stealing  . . . . . . . . . . . . . . . . .  2
+   3.  Association Hijacking 1  . . . . . . . . . . . . . . . . . . .  3
+   4.  Association Hijacking 2  . . . . . . . . . . . . . . . . . . .  6
+   5.  Bombing Attack (Amplification) 1 . . . . . . . . . . . . . . .  7
+   6.  Bombing Attack (Amplification) 2 . . . . . . . . . . . . . . .  9
+   7.  Association Redirection  . . . . . . . . . . . . . . . . . . . 10
+   8.  Bombing Attack (Amplification) 3 . . . . . . . . . . . . . . . 10
+   9.  Bombing Attack (Amplification) 4 . . . . . . . . . . . . . . . 11
+   10. Bombing Attack (amplification) 5 . . . . . . . . . . . . . . . 11
+   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+
+1.  Introduction
+
+   Stream Control Transmission Protocol, originally defined in
+   [RFC2960], is a multi-homed transport protocol.  As such, unique
+   security threats exists that are addressed in various ways within the
+   protocol itself.  This document describes certain security threats to
+   SCTP.  It also describes ways to mitigate these threats, in
+   particular by using techniques from the SCTP Specification Errata and
+   Issues memo [RFC4460].  These techniques are included in [RFC4960],
+   which obsoletes [RFC2960].  It is hoped that this information will
+   provide some useful background information for many of the newest
+   requirements spelled out in the [RFC4460] and included in [RFC4960].
+
+   This work and some of the changes that went into [RFC4460] and
+   [RFC4960] are much indebted to the paper on potential SCTP security
+   risks [EFFECTS] by Aura, Nikander, and Camarillo.  Without their
+   work, some of these changes would remain undocumented and potential
+   threats.
+
+   The rest of this document will concentrate on the various attacks
+   that were illustrated in [EFFECTS] and detail the preventative
+   measures now in place, if any, within the current SCTP standards.
+
+2.  Address Camping or Stealing
+
+   This attack is a form of denial of service attack crafted around
+   SCTP's multi-homing.  In effect, an illegitimate endpoint connects to
+   a server and "camps upon" or "holds up" a valid peer's address.  This
+   is done to prevent the legitimate peer from communicating with the
+   server.
+
+
+
+
+
+
+Stewart, et al.              Informational                      [Page 2]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+2.1.  Attack Details
+
+      +----------+            +----------+           +----------+
+      | Evil     |            |  Server  |           | Client   |
+      |     IP-A=+------------+          +-----------+=IP-C & D |
+      | Attacker |            |          |           | Victim   |
+      +----------+            +----------+           +----------+
+
+                            Figure 1: Camping
+
+   Consider the scenario illustrated in Figure 1.  The attacker
+   legitimately holds IP-A and wishes to prevent the 'Client-Victim'
+   from communicating with the 'Server'.  Note also that the client is
+   multi-homed.  The attacker first guesses the port number our client
+   will use in its association attempt.  It then uses this port and sets
+   up an association with the server listing not only IP-A but also IP-C
+   in its initial INIT chunk.  The server will respond and set up the
+   association, noting that the attacker is multi-homed and holds both
+   IP-A and IP-C.
+
+   Next, the victim sends in an INIT message listing its two valid
+   addresses, IP-C and IP-D.  In response, it will receive an ABORT
+   message with possibly an error code indicating that a new address was
+   added in its attempt to set up an existing association (a restart
+   with new addresses).  At this point, 'Client-Victim' is now prevented
+   from setting up an association with the server until the server
+   realizes that the attacker does not hold the address IP-C at some
+   future point by using a HEARTBEAT based mechanism.  See the
+   mitigation option subsection of this section.
+
+2.2.  Analysis
+
+   This particular attack was discussed in detail on the SCTP
+   implementors list in March of 2003.  Out of that discussion, changes
+   were made in the BSD implementation that are now present in
+   [RFC4960].  In close examination, this attack depends on a number of
+   specific things to occur.
+
+   1) The attacker must set up the association before the victim and
+      must correctly guess the port number that the victim will use.  If
+      the victim uses any other port number the attack will fail.
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Informational                      [Page 3]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+   2) SCTP's existing HEARTBEAT mechanism as defined already in
+      [RFC2960] will eventually catch this situation and abort the evil
+      attacker's association.  This may take several seconds based on
+      default HEARTBEAT timers but the attacker himself will lose any
+      association.
+
+   3) If the victim is either not multi-homed, or the address set that
+      it uses is completely camped upon by the attacker (in our example
+      if the attacker had included IP-D in its INIT as well), then the
+      client's INIT message would initiate an association between the
+      client and the server while destroying the association between the
+      attacker and the server.  From the servers' perspective, this is a
+      restart of the association.
+
+2.3.  Mitigation Option
+
+   [RFC4960] adds a new set of requirements to better counter this
+   attack.  In particular, the HEARTBEAT mechanism was modified so that
+   addresses unknown to an endpoint (i.e., presented in an INIT with no
+   pre-knowledge given by the application) enter a new state called
+   "UNCONFIRMED".  During the time that any address is UNCONFIRMED and
+   yet considered available, heartbeating will be done on those
+   UNCONFIRMED addresses at an accelerated rate.  This will lessen the
+   time that an attacker can "camp" on an address.  In particular, the
+   rate of heartbeats to UNCONFIRMED addresses is done every RTO.  Along
+   with this expanded rate of heartbeating, a new 64-bit random nonce is
+   required to be inside HEARTBEATs to UNCONFIRMED addresses.  In the
+   HEARTBEAT-ACK, the random nonce must match the value sent in the
+   HEARTBEAT before an address can leave the UNCONFIRMED state.  This
+   will prevent an attacker from generating false HEARTBEAT-ACKs with
+   the victim's source address(es).  In addition, clients that do not
+   need to use a specific port number should choose their port numbers
+   on a random basis.  This makes it hard for an attacker to guess that
+   number.
+
+3.  Association Hijacking 1
+
+   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-
+   middle, only a strong end-to-end security model can prevent this.
+   However, with the addition of the SCTP extension specified in
+   [RFC5061], an endpoint that is NOT a man-in-the-middle may be able to
+   assume another endpoint's association.
+
+
+
+
+
+
+
+
+Stewart, et al.              Informational                      [Page 4]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+3.1.  Attack Details
+
+   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
+   endpoint.  For example, DHCP may be used in a mobile network with
+   short IP address lifetimes to reassign IP addresses to migrant hosts.
+
+        IP-A                 DHCP-Server's       Peer-Server
+          |
+          |
+       1  |-DHCP-Rel(IP-A)---->|
+       2  |------ASCONF(ADD-IP(IP-B), DEL-IP(IP-A)---->XXlost
+         time
+          |
+          |-DHCP-new-net------>|
+       3  |<---Assign (IP-A)
+          |
+       4  |<------------Tag:X-DATA()------------------
+          |
+          |-------------INIT()------------------------>
+       5  |<------------INIT-ACK()---------------------
+          |
+       6  |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------>
+
+                   Figure 2: Association Hijack via DHCP
+
+   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
+   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
+   peer is no longer at IP-A.  Now at point 3, a new "evil" peer obtains
+   an address via DHCP and it happens to get the re-assigned address
+   IP-A.  Our 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 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 would of course hold tie-tags, which would list both sets
+   of tags that 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.
+
+   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
+   receive packets with destination address IP-A.
+
+
+
+
+
+
+
+Stewart, et al.              Informational                      [Page 5]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+3.2.  Analysis
+
+   This attack depends on a number of events:
+
+   1) Both endpoints must support the SCTP extension specified in
+      [RFC5061].
+
+   2) One of the endpoints must be using the SCTP extension for mobility
+      specified in [RFC5061].
+
+   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
+      concerned.
+
+   4) The true peer must not receive the ASCONF packet that deletes IP-A
+      and adds its new address to the peer before the new "evil" peer
+      gets control of the association.
+
+   5) The new "evil" peer must have an alternate address, aside from the
+      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
+      finally retransmits the ASCONF (from step 2).
+
+3.3.  Mitigation Option
+
+   [RFC4960] adds a new counter measure to this threat.  It is now
+   required that Tie-Tags in the State-Cookie parameter not be the
+   actual tags.  Instead, a new pair of two 32-bit nonces must be used
+   to represent the real tags within the association.  This prevents the
+   attacker from acquiring the real tags and thus prevents this attack.
+   Furthermore, the use of the SCTP extension specified in [RFC5061]
+   requires the use of the authentication mechanism defined in
+   [RFC4895].  This requires the attacker to be able to capture the
+   traffic during the association setup.  If in addition an endpoint-
+   pair shared key is used, capturing or intercepting these setup
+   messages does not enable the attacker to hijack the association.
+
+4.  Association Hijacking 2
+
+   Association hijacking is the ability of some other user to assume the
+   session created by another endpoint.  In cases where an attacker can
+   send packets using the victims IP-address as a source address and can
+   receive packets with the victims' address as a destination address,
+   the attacker can easily restart the association.  If the peer does
+   not pay attention to the restart notification, the attacker has taken
+   over the association.
+
+
+
+
+
+Stewart, et al.              Informational                      [Page 6]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+4.1.  Attack Details
+
+   Assume that an endpoint E1 having an IP-address A has an SCTP
+   association with endpoint E2.  After the attacker is able to receive
+   packets to destination address A and send packets with source address
+   A, the attacker can perform a full four-way handshake using the IP-
+   addresses and port numbers from the received packet.  E2 will
+   consider this a restart of the association.  If and only if the SCTP
+   user of E2 does not process the restart notification, the user will
+   not recognize that the association just restarted.  From this
+   perspective, the association has been hijacked.
+
+4.2.  Analysis
+
+   This attack depends on a number of circumstances:
+
+   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
+      local LAN is concerned.
+
+   2) The attacker must receive a packet belonging to the association or
+      connection.
+
+   3) The other endpoint's user does not pay attention to restart
+      notifications.
+
+4.3.  Mitigation Option
+
+   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 is not possible if the upper layer processes the restart
+   notifications provided by SCTP as described in section 10 of
+   [RFC2960] or [RFC4960].  Note that other IP protocols may also be
+   affected by this attack.
+
+5.  Bombing Attack (Amplification) 1
+
+   The bombing attack is a method to get a server to amplify packets to
+   an innocent victim.
+
+5.1.  Attack Details
+
+   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.
+   After the association is setup, the attacker makes a request for a
+   large data transfer.  After making the request, the attacker does not
+   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.
+
+
+
+Stewart, et al.              Informational                      [Page 7]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+   After waiting an appropriate time period, the attacker acknowledges
+   the data for the victim.  At some point, the attackers address is
+   considered unreachable since only data sent to the victims address is
+   acknowledged.  At this point, the attacker can send strategic
+   acknowledgments so that the server continues to send data to the
+   victim.
+
+   Alternatively, instead of stopping the sending of SACKs to enforce a
+   path failover, the attacker can use the ADD-IP extension to add the
+   address of the victim and make that address the primary path.
+
+5.2.  Analysis
+
+   This attack depends on a number of circumstances:
+
+   1) The victim must NOT support SCTP, otherwise it would respond with
+      an "out of the blue" (OOTB) abort.
+
+   2) The attacker must time its sending of acknowledgments correctly in
+      order to get its address into the failed state and the victim's
+      address as the only valid alternative.
+
+   3) The attacker must guess TSN values that are accepted by the
+      receiver once the bombing begins since it must acknowledge packets
+      it is no longer seeing.
+
+5.3.  Mitigation Option
+
+   [RFC4960] makes two changes to prevent this attack.  First, it
+   details proper handling of ICMP messages.  With SCTP, the ICMP
+   messages provide valuable clues to the SCTP stack that can be
+   verified with the tags for authenticity.  Proper handling of an ICMP
+   protocol unreachable (or equivalent) would cause the association
+   setup by the attacker to be immediately failed upon the first
+   retransmission to the victim's address.
+
+   The second change made in [RFC4960] is the requirement that no
+   address that is not CONFIRMED is allowed to have DATA chunks sent to
+   it.  This prevents the switch-over to the alternate address from
+   occurring, even when ICMP messages are lost in the network and
+   prevents any DATA chunks from being sent to any other destination
+   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
+   address.
+
+
+
+
+
+
+
+Stewart, et al.              Informational                      [Page 8]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+   An SCTP implementation should abort the association if it receives a
+   SACK acknowledging a TSN that has not been sent.  This makes TSN
+   guessing for the attacker quite hard because if the attacker
+   acknowledges one TSN too fast, the association will be aborted.
+
+6.  Bombing Attack (Amplification) 2
+
+   This attack allows an attacker to use an arbitrary SCTP endpoint to
+   send multiple packets to a victim in response to one packet.
+
+6.1.  Attack Details
+
+   The attacker sends an INIT listing multiple IP addresses of the
+   victim in the INIT's list of addresses to an arbitrary endpoint.
+   Optionally, it requests a long cookie lifetime.  Upon reception of
+   the INIT-ACK, it stores the cookie and sends it back to the other
+   endpoint.  When the other endpoint receives the COOKIE, it will send
+   back a COOKIE-ACK to the attacker and up to HB.Max.Burst HEARTBEATS
+   to the victim's address(es) (to confirm these addresses).  The victim
+   responds with ABORTs or ICMP messages resulting in the removal of the
+   TCB at the other endpoint.  The attacker can now resend the stored
+   cookie as long as it is valid, and this will again result in up to
+   HB.Max.Burst HEARTBEATs sent to the victim('s).
+
+6.2.  Analysis
+
+   The multiplication factor is limited by the number of addresses of
+   the victim and of the endpoint HB.Max.Burst.  Also, the shorter the
+   cookie lifetime, the earlier the attacker has to go through the
+   initial stage of sending an INIT instead of just sending the COOKIE.
+   It should also be noted that the attack is more effective if large
+   HEARTBEATs are used for path confirmation.
+
+6.3.  Mitigation Option
+
+   To limit the effectiveness of this attack, the new parameter
+   HB.Max.Burst was introduced in [RFC4960] and an endpoint should:
+
+   1) not allow very large cookie lifetimes, even if they are requested.
+
+   2) not use larger HB.Max.Burst parameter values than recommended.
+      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
+      chooses this approach will however slow down detection of
+      endpoints camping on valid addresses.
+
+   3) not use large HEARTBEATs for path confirmation.
+
+
+
+
+Stewart, et al.              Informational                      [Page 9]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+7.  Association Redirection
+
+   This attack allows an attacker to wrongly set up an association to a
+   different endpoint.
+
+7.1.  Attack Details
+
+   The attacker sends an INIT sourced from port 'X' and directed towards
+   port 'Y'.  When the INIT-ACK is returned, the attacker sends the
+   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 possibly sets
+   up the association using the modified port numbers.
+
+7.2.  Analysis
+
+   This attack depends on the failure of an SCTP implementation to store
+   and verify the ports within the COOKIE structure.
+
+7.3.  Mitigation Option
+
+   This attack is easily defeated by an implementation including the
+   ports of both the source and destination within the COOKIE.  If the
+   source and destination ports do not match those within the COOKIE
+   chunk when the COOKIE is returned, the SCTP implementation silently
+   discards the invalid COOKIE.
+
+8.  Bombing Attack (Amplification) 3
+
+   This attack allows an attacker to use an SCTP endpoint to send a
+   large number of packets in response to one packet.
+
+8.1.  Attack Details
+
+   The attacker sends a packet to an SCTP endpoint, which requires the
+   sending of multiple chunks.  If the SCTP endpoint does not support
+   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
+   address as the sources address, or it can be considered an attack
+   against the network.  Since the chunks, which need to be sent in
+   response to the received packet, may not fit into one packet, an
+   endpoint supporting bundling on the sending side might send multiple
+   packets.
+
+   Examples of these packets are packets containing a lot of unknown
+   chunks that require an ERROR chunk to be sent, known chunks that
+   initiate the sending of ERROR chunks, packets containing a lot of
+   HEARTBEAT chunks, and so on.
+
+
+
+
+Stewart, et al.              Informational                     [Page 10]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+8.2.  Analysis
+
+   This attack depends on the fact that the SCTP endpoint does not
+   support bundling on the sending side or provides a bad implementation
+   of bundling on the sending side.
+
+8.3.  Mitigation Option
+
+   First of all, path verification must happen before sending chunks
+   other than HEARTBEATs for path verification.  This ensures that the
+   above attack cannot be used against other hosts.  To avoid the
+   attack, an SCTP endpoint should implement bundling on the sending
+   side and should not send multiple packets in response.  If the SCTP
+   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.
+   The details of the required handling are described in [RFC4960].
+
+9.  Bombing Attack (Amplification) 4
+
+   This attack allows an attacker to use an SCTP server to send a larger
+   packet to a victim than it sent to the SCTP server.
+
+9.1.  Attack Details
+
+   The attacker sends packets using the victim's address as the source
+   address containing an INIT chunk to an SCTP Server.  The server then
+   sends a packet containing an INIT-ACK chunk to the victim, which is
+   most likely larger than the packet containing the INIT.
+
+9.2.  Analysis
+
+   This attack is a byte and not a packet amplification attack and,
+   without protocol changes, is hard to avoid.  A possible method to
+   avoid this attack would be the usage the PAD parameter defined in
+   [RFC4820].
+
+9.3.  Mitigation Option
+
+   A server should be implemented in a way that the generated INIT-ACK
+   chunks are as small as possible.
+
+10.  Bombing Attack (amplification) 5
+
+   This attack allows an attacker to use an SCTP endpoint to send a
+   large number of packets in response to one packet.
+
+
+
+
+
+
+Stewart, et al.              Informational                     [Page 11]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+10.1.  Attack Details
+
+   The attacker sends a packet to an SCTP endpoint, which requires the
+   sending of multiple chunks.  If the MTU towards the attacker is
+   smaller than the MTU towards the victim, the victim might need to
+   send more than one packet to send all the chunks.  The difference
+   between the MTUs might be extremely large if the attacker sends
+   malicious ICMP packets to make use of the path MTU discovery.
+
+10.2.  Analysis
+
+   This attack depends on the fact that an SCTP implementation might not
+   limit the number of response packets correctly.
+
+10.3.  Mitigation Option
+
+   First of all, path verification must happen before sending chunks
+   other than HEARTBEATs for path verification.  This makes sure that
+   the above attack cannot be used against other hosts.  To avoid the
+   attack, an SCTP endpoint should not send multiple packets in response
+   to a single packet.  The chunks not fitting in this packet should be
+   dropped.
+
+11.  Security Considerations
+
+   This document is about security; as such, there are no additional
+   security considerations.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2960]  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.
+
+   [RFC4460]  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.
+
+   [RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
+              Parameter for the Stream Control Transmission Protocol
+              (SCTP)", RFC 4820, March 2007.
+
+   [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
+              "Authenticated Chunks for Stream Control Transmission
+              Protocol (SCTP)", RFC 4895, August 2007.
+
+
+
+Stewart, et al.              Informational                     [Page 12]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
+              Kozuka, "Stream Control Transmission Protocol (SCTP)
+              Dynamic Address Reconfiguration", RFC 5061,
+              September 2007.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, June 2007.
+
+12.2.  Informative References
+
+   [EFFECTS]  Aura, T., Nikander, P., and G. Camarillo, "Effects of
+              Mobility and Multihoming on Transport-Layer Security",
+              Security and Privacy 2004, IEEE Symposium , URL http://
+              research.microsoft.com/users/tuomaura/Publications/
+              aura-nikander-camarillo-ssp04.pdf, May 2004.
+
+Authors' Addresses
+
+   Randall R. Stewart
+   Cisco Systems, Inc.
+   4785 Forest Drive
+   Suite 200
+   Columbia, SC  29206
+   USA
+
+   EMail: rrs@cisco.com
+
+
+   Michael Tuexen
+   Muenster Univ. of Applied Sciences
+   Stegerwaldstr. 39
+   48565 Steinfurt
+   Germany
+
+   EMail: tuexen@fh-muenster.de
+
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Gonzalo.Camarillo@ericsson.com
+
+
+
+
+
+
+
+Stewart, et al.              Informational                     [Page 13]
+
+RFC 5062                 SCTP Security Attacks            September 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   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
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Informational                     [Page 14]
+