idnits 2.17.1 draft-ietf-tsvwg-sctpthreat-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 649. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC2960, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2007) is 6163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2960 (ref. '1') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 4460 (ref. '2') (Obsoleted by RFC 9260) == Outdated reference: A later version (-05) exists of draft-ietf-tsvwg-2960bis-04 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-20 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Cisco Systems, Inc. 4 Expires: December 11, 2007 M. Tuexen 5 Muenster Univ. of Applied Sciences 6 G. Camarillo 7 Ericsson 8 June 9, 2007 10 Security Attacks Found Against SCTP and Current Countermeasures 11 draft-ietf-tsvwg-sctpthreat-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 11, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes certain security threats to SCTP. It also 45 describes ways to mitigate these threats, in particular by using 46 techniques from the SCTP Specification Errata and Issues memo (RFC 47 4460). These techniques are included in RFC 2960bis, which obsoletes 48 RFC 2960. It is hoped that this information will provide some useful 49 background information for many of the newest requirements spelled 50 out in the SCTP Specification Errata and Issues and included in RFC 51 2960bis. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Address Camping or stealing . . . . . . . . . . . . . . . . . 3 57 3. Association hijacking 1 . . . . . . . . . . . . . . . . . . . 5 58 4. Association hijacking 2 . . . . . . . . . . . . . . . . . . . 7 59 5. Bombing attack (amplification) 1 . . . . . . . . . . . . . . . 8 60 6. Bombing attack (amplification) 2 . . . . . . . . . . . . . . . 9 61 7. Association redirection . . . . . . . . . . . . . . . . . . . 10 62 8. Bombing attack (amplification) 3 . . . . . . . . . . . . . . . 11 63 9. Bombing attack (amplification) 4 . . . . . . . . . . . . . . . 12 64 10. Bombing attack (amplification) 5 . . . . . . . . . . . . . . . 12 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 13.2. Informative References . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . . . . 15 73 1. Introduction 75 Stream Control Transmission Protocol originally defined in RFC2960 76 [1] is a multi-homed transport protocol. As such, unique security 77 threats exists that are addressed in various ways within the protocol 78 itself. This document describes certain security threats to SCTP. 79 It also describes ways to mitigate these threats, in particular by 80 using techniques from the SCTP Specification Errata and Issues memo 81 (RFC4460 [2]). These techniques are included in RFC2960bis [3], 82 which obsoletes RFC2960 [1]. It is hoped that this information will 83 provide some useful background information for many of the newest 84 requirements spelled out in the SCTP-errata [2] and included in RFC 85 2960bis [3]. 87 This work and some of the changes that went into the SCTP-errata [2] 88 and RFC 2960bis [3] are much indebted to the paper on potential SCTP 89 security risks Effects [7] by Aura, Nikander and Camarillo. Without 90 their work some of these changes would remain undocumented and 91 potential threats. 93 The rest of this document will concentrate on the various attacks 94 that were illustrated in Effects [7] and detail what preventative 95 measures are now in place within the current SCTP standards (if any). 97 2. Address Camping or stealing 99 This attack is a form of denial of service attack crafted around 100 SCTP's multi-homing. In effect an illegitimate endpoint connects to 101 a server and "camps upon" or holds up a valid peers address. This is 102 done to prevent the legitimate peer from communicating with the 103 server. 105 2.1. Attack details 107 +----------+ +----------+ +----------+ 108 | Evil | | Server | | Client | 109 | IP-A=+------------+ +-----------+=IP-C & D | 110 | Attacker | | | | Victim | 111 +----------+ +----------+ +----------+ 113 Figure 1: Camping 115 Consider the scenario illustrated in Figure 1. The attacker 116 legitimately holds IP-A and wishes to prevent the 'Client-Victim' 117 from communication with the 'Server'. Note also that the client is 118 multi-homed. The attacker first guesses the port number our client 119 will use in its association attempt. It then uses this port and sets 120 up an association with the server listing not only IP-A but also IP-C 121 as well in its initial INIT chunk. The server will respond and setup 122 the association noting that the attacker is multi-homed holding both 123 IP-A and IP-C. 125 Next the victim sends in an INIT message listing its two valid 126 addresses IP-C and IP-D. In response it will receive an ABORT 127 message with possibly an error code indicating that a new address was 128 added in its attempt to setup an existing association (a restart with 129 new addresses). At this point 'Client-Victim' is now prevented from 130 setting up an association with the server until the server realizes 131 that the attacker does not hold the address IP-C at some future point 132 by using a HEARTBEAT based mechanism. See the mitigation option 133 subsection of this section. 135 2.2. Analysis 137 This particular attack was discussed in detail on the SCTP 138 implementors list in March of 2003. Out of that discussion changes 139 were made in the BSD implementation that are now present in the RFC 140 2960bis [3]. In close examination, this attack depends on a number 141 of specific things to occur. 143 1) The attacker must setup the association before the victim and must 144 correctly guess the port number that the victim will use. If the 145 victim uses any other port number the attack will fail. 147 2) SCTP's existing HEARTBEAT mechanism as defined already in RFC2960 148 [1] will eventually catch this situation and abort the evil 149 attackers association. This may take several seconds based on 150 default HEARTBEAT timers but the attacker himself will lose any 151 association. 153 3) If the victim is either not multi-homed, or the address set that 154 it uses is completely camped upon by the attacker (in our example 155 if the attacker had included IP-D in its INIT as well), then the 156 client's INIT message would initiate an association between the 157 client and the server while destroying the association between the 158 attacker and the server. From the servers' perspective this is a 159 restart of the association. 161 2.3. Mitigation option 163 RFC 2960bis [3] adds a new set of requirements to better counter this 164 attack. In particular the HEARTBEAT mechanism was modified so that 165 addresses unknown to an endpoint (i.e. presented in an INIT with no 166 pre-knowledge given by the application) enter a new state called 167 "UNCONFIRMED". During the time that any address is UNCONFIRMED and 168 yet considered available, heartbeating will be done on those 169 UNCONFIRMED addresses at an accelerated rate. This will lessen the 170 time that an attacker can "camp" on an address. In particular the 171 rate of heartbeats to UNCONFIRMED addresses is done every RTO. Along 172 with this expanded rate of heartbeating, a new 64 bit random nonce is 173 required to be inside HEARTBEATs to UNCONFIRMED addresses. In the 174 HEARTBEAT-ACK the random nonce must match the value sent in the 175 HEARTBEAT before an address can leave the UNCONFIRMED state. This 176 will prevent an attacker from generating false HEARTBEAT-ACKs with 177 the victims source address(es). In addition, clients which do not 178 need to use a specific port number should choose their port numbers 179 on a random base. This makes it hard for an attacker to guess that 180 number. 182 3. Association hijacking 1 184 Association hijacking is the ability of some other user to assume the 185 session created by another endpoint. In cases of a true man-in-the- 186 middle only a strong end-to-end security model can prevent this. 187 However with the addition of the ADD-IP [6] extension to SCTP an 188 endpoint that is NOT a man-in-the-middle may be able to assume 189 another endpoints association. 191 3.1. Attack details 193 The attack is made possible by any mechanism that lets an endpoint 194 acquire some other IP address that was recently in use by an SCTP 195 endpoint. For example in a mobile network DHCP may be in use with 196 short IP address lifetimes to reassign IP addresses to migrant hosts. 198 IP-A DHCP-Server's Peer-Server 199 | 200 | 201 1 |-DHCP-Rel(IP-A)---->| 202 2 |------ASCONF(ADD-IP(IP-B), DEL-IP(IP-A)---->XXlost 203 time 204 | 205 |-DHCP-new-net------>| 206 3 |<---Assign (IP-A) 207 | 208 4 |<------------Tag:X-DATA()------------------ 209 | 210 |-------------INIT()------------------------> 211 5 |<------------INIT-ACK()--------------------- 212 | 213 6 |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------> 215 Figure 2: Association Hijack via DHCP 217 At point 1, our valid client releases the IP address IP-A. It 218 presumably acquires a new address (IP-B) and sends an ASCONF to ADD 219 the new address and delete to old address at point 2, but this packet 220 is lost. Thus our peer (Peer-Server) has no idea that the former 221 peer is no longer at IP-A. Now at point 3 a new "evil" peer DHCP's 222 an address and happens to get the re-assigned address IP-A. Our 223 Peer-Server sends a chunk of DATA at point 4. This reveals to the 224 new owner of IP-A that the former owner of IP-A had an association 225 with Peer-Server. So at point 5 the new owner of IP-A sends an INIT. 226 The INIT-ACK is sent back and inside it is a COOKIE. The cookie 227 would of course hold tie-tags which would list both sets of tags 228 which could then be used at point 6 to add in any other IP addresses 229 that the owner of IP-A holds and thus acquire the association. 231 It should be noted that this attack is possible in general whenever 232 the attacker is able to send packets with source address IP-A and 233 receive packets with destination address IP-A. 235 3.2. Analysis 237 This attack depends on a number of events: 239 1) Both endpoints must support the ADD-IP [6] extension. 241 2) One of the endpoints must be using the ADD-IP [6] extension for 242 mobility. 244 3) The IP address must be acquired in such a way as to make the 245 endpoint the owner of that IP address as far as the network is 246 concerned. 248 4) The true peer must not get the ASCONF packet that deletes IP-A and 249 adds its new address to the peer before the new "evil" peer gets 250 control of the association. 252 5) The new "evil" peer must have an alternative address besides IP-A 253 that it can add to the association so it can delete IP-A 254 preventing the real peer from re-acquiring the association when it 255 finally retransmits the ASCONF (from step 2). 257 3.3. Mitigation option 259 RFC 2960bis [3] adds a new counter measure to this threat. It is now 260 required that Tie-Tags in the State-Cookie parameter not be the 261 actual tags. Instead a new pair of two 32 bit nonces must be used to 262 represent the real tags within the association. This prevents the 263 attacker from acquiring the real tags and thus prevents this attack. 264 Furthermore the use of the ADD-IP [6] extensions requires the use of 265 the authentication mechanism defined in SCTP-AUTH [5]. This requires 266 the attacker to be able to capture the traffic during the association 267 setup. If in addition an end-point pair shared key is used, 268 capturing or intercepting these setup messages does not enable the 269 attacker to hijack the association. 271 4. Association hijacking 2 273 Association hijacking is the ability of some other user to assume the 274 session created by another endpoint. In cases where an attacker can 275 send packets using the victims IP-address as a source address and can 276 receive packets with the victims' address as destination address the 277 attacker can easily restart the association. If the peer does not 278 pay attention to the restart notification the attacker has taken over 279 the association. 281 4.1. Attack details 283 Assume that an endpoint E1 having an IP-address A has an SCTP 284 association with endpoint E2. After the attacker is able to receive 285 packets with destination address A and send packet with source 286 address A the attacker can perform a full four-way handshake using 287 the the IP-addresses and port numbers from the received packet. E2 288 will consider this as a restart of the association. If and only if 289 the SCTP user of E2 does not process the restart notification the 290 user will not recognize that that association just restarted. From 291 his perspective the association has been hijacked. 293 4.2. Analysis 295 This attack depends on a number of circumstances: 297 1) The IP address must be acquired in such a way as to make the evil 298 endpoint the owner of that IP address as far as the network or 299 local LAN is concerned. 301 2) The attacker must receive a packet belonging to the association or 302 connection. 304 3) The other endpoints user does not pay attention to restart 305 notifications. 307 4.3. Mitigation option 309 It is important to note that this attack is not based on a weakness 310 of the protocol but on the ignorance of the upper layer. This attack 311 is not possible if the upper layer processes the restart 312 notifications provided by SCTP as described in section 10 of RFC2960 313 [1] or RFC 2960bis [3]. Note that other IP protocols may also be 314 effected by this attack. 316 5. Bombing attack (amplification) 1 318 The bombing attack is a method to get a server to amplify packets to 319 an innocent victim. 321 5.1. Attack details 323 This attack is performed by setting up an association with a peer and 324 listing the victims IP address in the INIT's list of addresses. 325 After the association is setup, the attacker makes a request for a 326 large data transfer. After making the request the attacker does not 327 acknowledge data sent to it. This then causes the server to re- 328 transmit the data to the alternate address i.e. that of the victim. 329 After waiting an appropriate time period the attacker acknowledges 330 the data for the victim. At some point the attackers address is 331 considered unreachable since only data sent to the victims address is 332 acknowledged. At this point the attacker can send strategic 333 acknowledgments so that the server continues to send data to the 334 victim. 336 Alternatively, instead of stopping the sending of SACKs to enforce a 337 path failover, the attacker can use the ADD-IP extension to add the 338 address of the victim and make that address the primary path. 340 5.2. Analysis 342 This attack depends on a number of circumstances: 344 1) The victim must NOT support SCTP, otherwise it would respond with 345 an OOTB abort. 347 2) The attacker must time its sending of acknowledgments correctly in 348 order to get its address into the failed state and the victims 349 address as the only valid alternative. 351 3) The attacker must guess TSN values that are accepted by the 352 receiver once the bombing begins since it must acknowledge packets 353 it no longer is seeing. 355 5.3. Mitigation option 357 RFC 2960bis [3] makes two changes to prevent this attack. First it 358 details out proper handling of ICMP messages. With SCTP the ICMP 359 messages provide valuable clues to the SCTP stack that can be 360 verified with the tags for authenticity. Proper handling of an ICMP 361 protocol unreachable (or equivalent) would cause the association 362 setup by the attacker to be immediately failed upon the first 363 retransmission to the victims address. 365 The second change made in RFC 2960bis [3] is the requirement that no 366 address that is not CONFIRMED is allowed to have DATA chunks sent to 367 it. This prevents the switch-over to the alternate address from 368 occurring even when ICMP messages are lost in the network and 369 prevents any DATA chunks from being sent to any other destination 370 other then the attacker itself. This also prevents the alternative 371 way of using ADD-IP to add the new address and make it the primary 372 address. 374 An SCTP implementation should abort the association if it receives a 375 SACK acknowledging a TSN which has not been sent. This makes TSN 376 guessing for the attacker quite hard because if the attacker 377 acknowledges one TSN too fast the association will be aborted. 379 6. Bombing attack (amplification) 2 381 This attack allows an attacker to use an arbitrary SCTP endpoint to 382 send multiple packets to a victim in response to one packet. 384 6.1. Attack details 386 The attacker sends an INIT listing multiple IP addresses of the 387 victim in the INIT's list of addresses to an arbitrary endpoint. 388 Optionally it request a long cookie life time. Upon reception of the 389 INIT-ACK it stores the cookie and sends it back to the other 390 endpoint. When the other endpoint receives the COOKIE it will send 391 back a COOKIE-ACK to the attacker and up to HB.Max.Burst HEARTBEATS 392 to the victim's address(es) (to confirm these addresses). The victim 393 responds with ABORTs or ICMP messages resulting in the removal of the 394 TCB at the other endpoint. The attacker can now resend the stored 395 cookie as long as it is valid and this will again result in up to 396 HB.Max.Burst HEARTBEATs sent to the victim('s). 398 6.2. Analysis 400 The multiplication factor is limited by the number of addresses of 401 the victim and of the end point HB.Max.Burst. Also the shorter the 402 cookie life time is, the earlier the attacker has to go through the 403 initial stage of sending an INIT instead of the just sending the 404 COOKIE. It should also be noted that the attack is more effective if 405 large HEARTBEATs are used for path confirmation. 407 6.3. Mitigation option 409 To limit the effectiveness of this attack the new parameter 410 HB.Max.Burst was introduced in RFC 2960bis [3] and an end point 411 should: 413 1) not allow very large cookie lifetimes, even if they are requested. 415 2) not use larger HB.Max.Burst parameter values than recommended. 416 Note that an endpoint may decide to send only one Heartbeat per 417 RTT instead of the maximum (i.e. HB.Max.Burst). An endpoint that 418 chooses this approach will however slow down detection of 419 endpoints camping on valid addresses. 421 3) not use large HEARTBEATs for path confirmation. 423 7. Association redirection 425 This attack allows an attacker to wrongly setup an association to a 426 different endpoint. 428 7.1. Attack details 430 The attacker sends an INIT sourced from port 'X' and directed towards 431 port 'Y'. When the INIT-ACK is returned the attacker sends the 432 COOKIE-ECHO chunk and either places a different destination or source 433 port in the SCTP common header, i.e., X+1 or Y+1. This then sets up 434 the association with possibly other endpoints. 436 7.2. Analysis 438 This attack depends on the failure of an SCTP implementation to store 439 and verify the ports within the COOKIE structure. 441 7.3. Mitigation option 443 This attack is easily defeated by an implementation including the 444 ports of both the source and destination within the COOKIE. When the 445 COOKIE is returned if the source and destination ports do not match 446 those within the COOKIE chunk, the SCTP implementation silently 447 discards the invalid COOKIE. 449 8. Bombing attack (amplification) 3 451 This attack allows an attacker to use an SCTP endpoint to send a 452 large number of packets in response to one packet. 454 8.1. Attack details 456 The attacker sends a packet to an SCTP endpoint which requires the 457 sending of multiple chunks. If the SCTP endpoint does not support 458 bundling on the sending side it might send each chunk per packet. 459 These packets can either be sent to a victim by using the victim's 460 address as the sources address or it can be considered an attack 461 against the network. Since the chunks which need to be send in 462 response to the received packet may not fit into one packet an 463 endpoint supporting bundling on the sending side might send multiple 464 packets. 466 Examples of these packets are packets containing a lot of unknown 467 chunks which require an ERROR chunk to be sent, known chunks which 468 initiate the sending of ERROR chunks, packets containing a lot of 469 HEARTBEAT chunks and so on. 471 8.2. Analysis 473 This attack depends on the fact that the SCTP endpoint does not 474 support bundling on the sending side or provides a bad implementation 475 of bundling on the sending side. 477 8.3. Mitigation option 479 First of all, path verification must happen before sending other 480 chunks than HEARTBEATs for path verification. This makes sure that 481 the above attack can not be used against other hosts. To avoid the 482 attack, an SCTP endpoint should implement bundling on the sending 483 side and should not send multiple packets in response. If the SCTP 484 endpoint does not support bundling on the sending side it should not 485 send in general more than one packet in response to a received one. 486 The details of the required handling are described in the RFC 2960bis 487 [3]. 489 9. Bombing attack (amplification) 4 491 This attack allows an attacker to use an SCTP server to send a larger 492 packets to a victim than it sent to the SCTP server. 494 9.1. Attack details 496 The attacker sends packets using the victim's address as the source 497 address containing an INIT chunk to an SCTP Server. The server then 498 sends an packet containing an INIT-ACK chunk to the victim, which is 499 most likely larger than the packet containing the INIT. 501 9.2. Analysis 503 This attack is a byte and not a packet amplification attack and 504 without protocol changes hard to avoid. A possible method would be 505 the usage of the PAD parameter defined in SCTP-PAD [4]. 507 9.3. Mitigation option 509 A server should be implemented in a way that the generated INIT-ACK 510 chunks are as small as possible. 512 10. Bombing attack (amplification) 5 514 This attack allows an attacker to use an SCTP endpoint to send a 515 large number of packets in response to one packet. 517 10.1. Attack details 519 The attacker sends a packet to an SCTP endpoint which requires the 520 sending of multiple chunks. If the MTU towards the attacker is 521 smaller than the MTU towards the victim, the victim might need to 522 send more than one packet to send all the chunks. The difference 523 between the MTUs might be extremely large if the attacker sends 524 malicious ICMP packets to make use of the path MTU discovery. 526 10.2. Analysis 528 This attack depends on the fact that an SCTP implementation might not 529 not limit the number of response packets correctly. 531 10.3. Mitigation option 533 First of all, path verification must happen before sending other 534 chunks than HEARTBEATs for path verification. This makes sure that 535 the above attack can not be used against other hosts. To avoid the 536 attack, an SCTP endpoint should not send multiple packets in response 537 to a single packet. The chunks not fitting in this packet should be 538 dropped. 540 11. Security Considerations 542 This document is about security and there is nothing to be added to 543 it in this section. 545 12. IANA considerations 547 There are no actions required from IANA. 549 13. References 551 13.1. Normative References 553 [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 554 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 555 "Stream Control Transmission Protocol", RFC 2960, October 2000. 557 [2] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. 558 Tuexen, "Stream Control Transmission Protocol (SCTP) 559 Specification Errata and Issues", RFC 4460, April 2006. 561 [3] Stewart, R., "Stream Control Transmission Protocol", 562 draft-ietf-tsvwg-2960bis-04 (work in progress), April 2007. 564 [4] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 565 Parameter for the Stream Control Transmission Protocol (SCTP)", 566 RFC 4820, March 2007. 568 [5] Tuexen, M., "Authenticated Chunks for Stream Control 569 Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctp-auth-08 570 (work in progress), February 2007. 572 [6] Stewart, R., "Stream Control Transmission Protocol (SCTP) 573 Dynamic Address Reconfiguration", 574 draft-ietf-tsvwg-addip-sctp-20 (work in progress), April 2007. 576 13.2. Informative References 578 [7] Aura, T., Nikander, P., and G. Camarillo, "Effects of Mobility 579 and Multihoming on Transport-Layer Security", Security and 580 Privacy 2004, IEEE Symposium , URL http:// 581 research.microsoft.com/users/tuomaura/Publications/ 582 aura-nikander-camarillo-ssp04.pdf, May 2004. 584 Authors' Addresses 586 Randall R. Stewart 587 Cisco Systems, Inc. 588 4785 Forest Drive 589 Suite 200 590 Columbia, SC 29206 591 USA 593 Email: rrs@cisco.com 595 Michael Tuexen 596 Muenster Univ. of Applied Sciences 597 Stegerwaldstr. 39 598 48565 Steinfurt 599 Germany 601 Email: tuexen@fh-muenster.de 603 Gonzalo Camarillo 604 Ericsson 605 Hirsalantie 11 606 Jorvas 02420 607 Finland 609 Email: Gonzalo.Camarillo@ericsson.com 611 Full Copyright Statement 613 Copyright (C) The IETF Trust (2007). 615 This document is subject to the rights, licenses and restrictions 616 contained in BCP 78, and except as set forth therein, the authors 617 retain all their rights. 619 This document and the information contained herein are provided on an 620 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 621 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 622 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 623 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 624 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 625 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 627 Intellectual Property 629 The IETF takes no position regarding the validity or scope of any 630 Intellectual Property Rights or other rights that might be claimed to 631 pertain to the implementation or use of the technology described in 632 this document or the extent to which any license under such rights 633 might or might not be available; nor does it represent that it has 634 made any independent effort to identify any such rights. Information 635 on the procedures with respect to rights in RFC documents can be 636 found in BCP 78 and BCP 79. 638 Copies of IPR disclosures made to the IETF Secretariat and any 639 assurances of licenses to be made available, or the result of an 640 attempt made to obtain a general license or permission for the use of 641 such proprietary rights by implementers or users of this 642 specification can be obtained from the IETF on-line IPR repository at 643 http://www.ietf.org/ipr. 645 The IETF invites any interested party to bring to its attention any 646 copyrights, patents or patent applications, or other proprietary 647 rights that may cover technology that may be required to implement 648 this standard. Please address the information to the IETF at 649 ietf-ipr@ietf.org. 651 Acknowledgment 653 Funding for the RFC Editor function is provided by the IETF 654 Administrative Support Activity (IASA).