idnits 2.17.1 draft-ietf-tsvwg-sctpthreat-05.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 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 657. 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 13, 2007) is 6162 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 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 4460 (Obsoleted by RFC 9260) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-21 Summary: 3 errors (**), 0 flaws (~~), 3 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 15, 2007 M. Tuexen 5 Muenster Univ. of Applied Sciences 6 G. Camarillo 7 Ericsson 8 June 13, 2007 10 Security Attacks Found Against SCTP and Current Countermeasures 11 draft-ietf-tsvwg-sctpthreat-05.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 15, 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 4960, 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 4960. 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 . . . . . . . . . . . . . . . 10 61 7. Association redirection . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . 16 73 1. Introduction 75 Stream Control Transmission Protocol originally defined in [RFC2960] 76 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]). These techniques are included in 82 [I-D.ietf-tsvwg-2960bis], which obsoletes [RFC2960]. It is hoped 83 that this information will provide some useful background information 84 for many of the newest requirements spelled out in the [RFC4460] and 85 included in [I-D.ietf-tsvwg-2960bis]. 87 This work and some of the changes that went into the [RFC4460] and 88 [I-D.ietf-tsvwg-2960bis] are much indebted to the paper on potential 89 SCTP security risks Effects [effects] by Aura, Nikander and 90 Camarillo. Without their work some of these changes would remain 91 undocumented and potential threats. 93 The rest of this document will concentrate on the various attacks 94 that were illustrated in Effects [effects] and detail what 95 preventative measures are now in place within the current SCTP 96 standards (if any). 98 2. Address Camping or stealing 100 This attack is a form of denial of service attack crafted around 101 SCTP's multi-homing. In effect an illegitimate endpoint connects to 102 a server and "camps upon" or holds up a valid peers address. This is 103 done to prevent the legitimate peer from communicating with the 104 server. 106 2.1. Attack details 108 +----------+ +----------+ +----------+ 109 | Evil | | Server | | Client | 110 | IP-A=+------------+ +-----------+=IP-C & D | 111 | Attacker | | | | Victim | 112 +----------+ +----------+ +----------+ 114 Figure 1: Camping 116 Consider the scenario illustrated in Figure 1. The attacker 117 legitimately holds IP-A and wishes to prevent the 'Client-Victim' 118 from communication with the 'Server'. Note also that the client is 119 multi-homed. The attacker first guesses the port number our client 120 will use in its association attempt. It then uses this port and sets 121 up an association with the server listing not only IP-A but also IP-C 122 as well in its initial INIT chunk. The server will respond and setup 123 the association noting that the attacker is multi-homed holding both 124 IP-A and IP-C. 126 Next the victim sends in an INIT message listing its two valid 127 addresses IP-C and IP-D. In response it will receive an ABORT 128 message with possibly an error code indicating that a new address was 129 added in its attempt to setup an existing association (a restart with 130 new addresses). At this point 'Client-Victim' is now prevented from 131 setting up an association with the server until the server realizes 132 that the attacker does not hold the address IP-C at some future point 133 by using a HEARTBEAT based mechanism. See the mitigation option 134 subsection of this section. 136 2.2. Analysis 138 This particular attack was discussed in detail on the SCTP 139 implementors list in March of 2003. Out of that discussion changes 140 were made in the BSD implementation that are now present in the 141 [I-D.ietf-tsvwg-2960bis]. In close examination, this attack depends 142 on a number of specific things to occur. 144 1) The attacker must setup the association before the victim and must 145 correctly guess the port number that the victim will use. If the 146 victim uses any other port number the attack will fail. 148 2) SCTP's existing HEARTBEAT mechanism as defined already in 149 [RFC2960] will eventually catch this situation and abort the evil 150 attackers association. This may take several seconds based on 151 default HEARTBEAT timers but the attacker himself will lose any 152 association. 154 3) If the victim is either not multi-homed, or the address set that 155 it uses is completely camped upon by the attacker (in our example 156 if the attacker had included IP-D in its INIT as well), then the 157 client's INIT message would initiate an association between the 158 client and the server while destroying the association between the 159 attacker and the server. From the servers' perspective this is a 160 restart of the association. 162 2.3. Mitigation option 164 [I-D.ietf-tsvwg-2960bis] adds a new set of requirements to better 165 counter this attack. In particular the HEARTBEAT mechanism was 166 modified so that addresses unknown to an endpoint (i.e. presented in 167 an INIT with no pre-knowledge given by the application) enter a new 168 state called "UNCONFIRMED". During the time that any address is 169 UNCONFIRMED and yet considered available, heartbeating will be done 170 on those UNCONFIRMED addresses at an accelerated rate. This will 171 lessen the time that an attacker can "camp" on an address. In 172 particular the rate of heartbeats to UNCONFIRMED addresses is done 173 every RTO. Along with this expanded rate of heartbeating, a new 64 174 bit random nonce is required to be inside HEARTBEATs to UNCONFIRMED 175 addresses. In the HEARTBEAT-ACK the random nonce must match the 176 value sent in the HEARTBEAT before an address can leave the 177 UNCONFIRMED state. This will prevent an attacker from generating 178 false HEARTBEAT-ACKs with the victims source address(es). In 179 addition, clients which do not need to use a specific port number 180 should choose their port numbers on a random base. This makes it 181 hard for an attacker to guess that number. 183 3. Association hijacking 1 185 Association hijacking is the ability of some other user to assume the 186 session created by another endpoint. In cases of a true man-in-the- 187 middle only a strong end-to-end security model can prevent this. 188 However with the addition of the [I-D.ietf-tsvwg-addip-sctp] 189 extension to SCTP an endpoint that is NOT a man-in-the-middle may be 190 able to assume another endpoints association. 192 3.1. Attack details 194 The attack is made possible by any mechanism that lets an endpoint 195 acquire some other IP address that was recently in use by an SCTP 196 endpoint. For example in a mobile network DHCP may be in use with 197 short IP address lifetimes to reassign IP addresses to migrant hosts. 199 IP-A DHCP-Server's Peer-Server 200 | 201 | 202 1 |-DHCP-Rel(IP-A)---->| 203 2 |------ASCONF(ADD-IP(IP-B), DEL-IP(IP-A)---->XXlost 204 time 205 | 206 |-DHCP-new-net------>| 207 3 |<---Assign (IP-A) 208 | 209 4 |<------------Tag:X-DATA()------------------ 210 | 211 |-------------INIT()------------------------> 212 5 |<------------INIT-ACK()--------------------- 213 | 214 6 |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------> 216 Figure 2: Association Hijack via DHCP 218 At point 1, our valid client releases the IP address IP-A. It 219 presumably acquires a new address (IP-B) and sends an ASCONF to ADD 220 the new address and delete to old address at point 2, but this packet 221 is lost. Thus our peer (Peer-Server) has no idea that the former 222 peer is no longer at IP-A. Now at point 3 a new "evil" peer DHCP's 223 an address and happens to get the re-assigned address IP-A. Our 224 Peer-Server sends a chunk of DATA at point 4. This reveals to the 225 new owner of IP-A that the former owner of IP-A had an association 226 with Peer-Server. So at point 5 the new owner of IP-A sends an INIT. 227 The INIT-ACK is sent back and inside it is a COOKIE. The cookie 228 would of course hold tie-tags which would list both sets of tags 229 which could then be used at point 6 to add in any other IP addresses 230 that the owner of IP-A holds and thus acquire the association. 232 It should be noted that this attack is possible in general whenever 233 the attacker is able to send packets with source address IP-A and 234 receive packets with destination address IP-A. 236 3.2. Analysis 238 This attack depends on a number of events: 240 1) Both endpoints must support the [I-D.ietf-tsvwg-addip-sctp] 241 extension. 243 2) One of the endpoints must be using the [I-D.ietf-tsvwg-addip-sctp] 244 extension for mobility. 246 3) The IP address must be acquired in such a way as to make the 247 endpoint the owner of that IP address as far as the network is 248 concerned. 250 4) The true peer must not get the ASCONF packet that deletes IP-A and 251 adds its new address to the peer before the new "evil" peer gets 252 control of the association. 254 5) The new "evil" peer must have an alternative address besides IP-A 255 that it can add to the association so it can delete IP-A 256 preventing the real peer from re-acquiring the association when it 257 finally retransmits the ASCONF (from step 2). 259 3.3. Mitigation option 261 [I-D.ietf-tsvwg-2960bis] adds a new counter measure to this threat. 262 It is now required that Tie-Tags in the State-Cookie parameter not be 263 the actual tags. Instead a new pair of two 32 bit nonces must be 264 used to represent the real tags within the association. This 265 prevents the attacker from acquiring the real tags and thus prevents 266 this attack. Furthermore the use of the [I-D.ietf-tsvwg-addip-sctp] 267 extensions requires the use of the authentication mechanism defined 268 in [I-D.ietf-tsvwg-sctp-auth]. This requires the attacker to be able 269 to capture the traffic during the association setup. If in addition 270 an end-point pair shared key is used, capturing or intercepting these 271 setup messages does not enable the attacker to hijack the 272 association. 274 4. Association hijacking 2 276 Association hijacking is the ability of some other user to assume the 277 session created by another endpoint. In cases where an attacker can 278 send packets using the victims IP-address as a source address and can 279 receive packets with the victims' address as destination address the 280 attacker can easily restart the association. If the peer does not 281 pay attention to the restart notification the attacker has taken over 282 the association. 284 4.1. Attack details 286 Assume that an endpoint E1 having an IP-address A has an SCTP 287 association with endpoint E2. After the attacker is able to receive 288 packets with destination address A and send packet with source 289 address A the attacker can perform a full four-way handshake using 290 the the IP-addresses and port numbers from the received packet. E2 291 will consider this as a restart of the association. If and only if 292 the SCTP user of E2 does not process the restart notification the 293 user will not recognize that that association just restarted. From 294 his perspective the association has been hijacked. 296 4.2. Analysis 298 This attack depends on a number of circumstances: 300 1) The IP address must be acquired in such a way as to make the evil 301 endpoint the owner of that IP address as far as the network or 302 local LAN is concerned. 304 2) The attacker must receive a packet belonging to the association or 305 connection. 307 3) The other endpoints user does not pay attention to restart 308 notifications. 310 4.3. Mitigation option 312 It is important to note that this attack is not based on a weakness 313 of the protocol but on the ignorance of the upper layer. This attack 314 is not possible if the upper layer processes the restart 315 notifications provided by SCTP as described in section 10 of 316 [RFC2960] or [I-D.ietf-tsvwg-2960bis]. Note that other IP protocols 317 may also be effected by this attack. 319 5. Bombing attack (amplification) 1 321 The bombing attack is a method to get a server to amplify packets to 322 an innocent victim. 324 5.1. Attack details 326 This attack is performed by setting up an association with a peer and 327 listing the victims IP address in the INIT's list of addresses. 328 After the association is setup, the attacker makes a request for a 329 large data transfer. After making the request the attacker does not 330 acknowledge data sent to it. This then causes the server to re- 331 transmit the data to the alternate address i.e. that of the victim. 332 After waiting an appropriate time period the attacker acknowledges 333 the data for the victim. At some point the attackers address is 334 considered unreachable since only data sent to the victims address is 335 acknowledged. At this point the attacker can send strategic 336 acknowledgments so that the server continues to send data to the 337 victim. 339 Alternatively, instead of stopping the sending of SACKs to enforce a 340 path failover, the attacker can use the ADD-IP extension to add the 341 address of the victim and make that address the primary path. 343 5.2. Analysis 345 This attack depends on a number of circumstances: 347 1) The victim must NOT support SCTP, otherwise it would respond with 348 an OOTB abort. 350 2) The attacker must time its sending of acknowledgments correctly in 351 order to get its address into the failed state and the victims 352 address as the only valid alternative. 354 3) The attacker must guess TSN values that are accepted by the 355 receiver once the bombing begins since it must acknowledge packets 356 it no longer is seeing. 358 5.3. Mitigation option 360 [I-D.ietf-tsvwg-2960bis] makes two changes to prevent this attack. 361 First it details out proper handling of ICMP messages. With SCTP the 362 ICMP messages provide valuable clues to the SCTP stack that can be 363 verified with the tags for authenticity. Proper handling of an ICMP 364 protocol unreachable (or equivalent) would cause the association 365 setup by the attacker to be immediately failed upon the first 366 retransmission to the victims address. 368 The second change made in [I-D.ietf-tsvwg-2960bis] is the requirement 369 that no address that is not CONFIRMED is allowed to have DATA chunks 370 sent to it. This prevents the switch-over to the alternate address 371 from occurring even when ICMP messages are lost in the network and 372 prevents any DATA chunks from being sent to any other destination 373 other then the attacker itself. This also prevents the alternative 374 way of using ADD-IP to add the new address and make it the primary 375 address. 377 An SCTP implementation should abort the association if it receives a 378 SACK acknowledging a TSN which has not been sent. This makes TSN 379 guessing for the attacker quite hard because if the attacker 380 acknowledges one TSN too fast the association will be aborted. 382 6. Bombing attack (amplification) 2 384 This attack allows an attacker to use an arbitrary SCTP endpoint to 385 send multiple packets to a victim in response to one packet. 387 6.1. Attack details 389 The attacker sends an INIT listing multiple IP addresses of the 390 victim in the INIT's list of addresses to an arbitrary endpoint. 391 Optionally it request a long cookie life time. Upon reception of the 392 INIT-ACK it stores the cookie and sends it back to the other 393 endpoint. When the other endpoint receives the COOKIE it will send 394 back a COOKIE-ACK to the attacker and up to HB.Max.Burst HEARTBEATS 395 to the victim's address(es) (to confirm these addresses). The victim 396 responds with ABORTs or ICMP messages resulting in the removal of the 397 TCB at the other endpoint. The attacker can now resend the stored 398 cookie as long as it is valid and this will again result in up to 399 HB.Max.Burst HEARTBEATs sent to the victim('s). 401 6.2. Analysis 403 The multiplication factor is limited by the number of addresses of 404 the victim and of the end point HB.Max.Burst. Also the shorter the 405 cookie life time is, the earlier the attacker has to go through the 406 initial stage of sending an INIT instead of the just sending the 407 COOKIE. It should also be noted that the attack is more effective if 408 large HEARTBEATs are used for path confirmation. 410 6.3. Mitigation option 412 To limit the effectiveness of this attack the new parameter 413 HB.Max.Burst was introduced in [I-D.ietf-tsvwg-2960bis] and an end 414 point should: 416 1) not allow very large cookie lifetimes, even if they are requested. 418 2) not use larger HB.Max.Burst parameter values than recommended. 419 Note that an endpoint may decide to send only one Heartbeat per 420 RTT instead of the maximum (i.e. HB.Max.Burst). An endpoint that 421 chooses this approach will however slow down detection of 422 endpoints camping on valid addresses. 424 3) not use large HEARTBEATs for path confirmation. 426 7. Association redirection 428 This attack allows an attacker to wrongly setup an association to a 429 different endpoint. 431 7.1. Attack details 433 The attacker sends an INIT sourced from port 'X' and directed towards 434 port 'Y'. When the INIT-ACK is returned the attacker sends the 435 COOKIE-ECHO chunk and either places a different destination or source 436 port in the SCTP common header, i.e., X+1 or Y+1. This then sets up 437 the association with possibly other endpoints. 439 7.2. Analysis 441 This attack depends on the failure of an SCTP implementation to store 442 and verify the ports within the COOKIE structure. 444 7.3. Mitigation option 446 This attack is easily defeated by an implementation including the 447 ports of both the source and destination within the COOKIE. When the 448 COOKIE is returned if the source and destination ports do not match 449 those within the COOKIE chunk, the SCTP implementation silently 450 discards the invalid COOKIE. 452 8. Bombing attack (amplification) 3 454 This attack allows an attacker to use an SCTP endpoint to send a 455 large number of packets in response to one packet. 457 8.1. Attack details 459 The attacker sends a packet to an SCTP endpoint which requires the 460 sending of multiple chunks. If the SCTP endpoint does not support 461 bundling on the sending side it might send each chunk per packet. 462 These packets can either be sent to a victim by using the victim's 463 address as the sources address or it can be considered an attack 464 against the network. Since the chunks which need to be send in 465 response to the received packet may not fit into one packet an 466 endpoint supporting bundling on the sending side might send multiple 467 packets. 469 Examples of these packets are packets containing a lot of unknown 470 chunks which require an ERROR chunk to be sent, known chunks which 471 initiate the sending of ERROR chunks, packets containing a lot of 472 HEARTBEAT chunks and so on. 474 8.2. Analysis 476 This attack depends on the fact that the SCTP endpoint does not 477 support bundling on the sending side or provides a bad implementation 478 of bundling on the sending side. 480 8.3. Mitigation option 482 First of all, path verification must happen before sending other 483 chunks than HEARTBEATs for path verification. This makes sure that 484 the above attack can not be used against other hosts. To avoid the 485 attack, an SCTP endpoint should implement bundling on the sending 486 side and should not send multiple packets in response. If the SCTP 487 endpoint does not support bundling on the sending side it should not 488 send in general more than one packet in response to a received one. 489 The details of the required handling are described in the 490 [I-D.ietf-tsvwg-2960bis]. 492 9. Bombing attack (amplification) 4 494 This attack allows an attacker to use an SCTP server to send a larger 495 packets to a victim than it sent to the SCTP server. 497 9.1. Attack details 499 The attacker sends packets using the victim's address as the source 500 address containing an INIT chunk to an SCTP Server. The server then 501 sends an packet containing an INIT-ACK chunk to the victim, which is 502 most likely larger than the packet containing the INIT. 504 9.2. Analysis 506 This attack is a byte and not a packet amplification attack and 507 without protocol changes hard to avoid. A possible method would be 508 the usage of the PAD parameter defined in [RFC4820]. 510 9.3. Mitigation option 512 A server should be implemented in a way that the generated INIT-ACK 513 chunks are as small as possible. 515 10. Bombing attack (amplification) 5 517 This attack allows an attacker to use an SCTP endpoint to send a 518 large number of packets in response to one packet. 520 10.1. Attack details 522 The attacker sends a packet to an SCTP endpoint which requires the 523 sending of multiple chunks. If the MTU towards the attacker is 524 smaller than the MTU towards the victim, the victim might need to 525 send more than one packet to send all the chunks. The difference 526 between the MTUs might be extremely large if the attacker sends 527 malicious ICMP packets to make use of the path MTU discovery. 529 10.2. Analysis 531 This attack depends on the fact that an SCTP implementation might not 532 not limit the number of response packets correctly. 534 10.3. Mitigation option 536 First of all, path verification must happen before sending other 537 chunks than HEARTBEATs for path verification. This makes sure that 538 the above attack can not be used against other hosts. To avoid the 539 attack, an SCTP endpoint should not send multiple packets in response 540 to a single packet. The chunks not fitting in this packet should be 541 dropped. 543 11. Security Considerations 545 This document is about security and there is nothing to be added to 546 it in this section. 548 12. IANA considerations 550 There are no actions required from IANA. 552 13. References 554 13.1. Normative References 556 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 557 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 558 Zhang, L., and V. Paxson, "Stream Control Transmission 559 Protocol", RFC 2960, October 2000. 561 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 562 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 563 Specification Errata and Issues", RFC 4460, April 2006. 565 [I-D.ietf-tsvwg-2960bis] 566 Stewart, R., "Stream Control Transmission Protocol", 567 draft-ietf-tsvwg-2960bis-05 (work in progress), June 2007. 569 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 570 Parameter for the Stream Control Transmission Protocol 571 (SCTP)", RFC 4820, March 2007. 573 [I-D.ietf-tsvwg-sctp-auth] 574 Tuexen, M., "Authenticated Chunks for Stream Control 575 Transmission Protocol (SCTP)", 576 draft-ietf-tsvwg-sctp-auth-08 (work in progress), 577 February 2007. 579 [I-D.ietf-tsvwg-addip-sctp] 580 Stewart, R., "Stream Control Transmission Protocol (SCTP) 581 Dynamic Address Reconfiguration", 582 draft-ietf-tsvwg-addip-sctp-21 (work in progress), 583 June 2007. 585 13.2. Informative References 587 [effects] Aura, T., Nikander, P., and G. Camarillo, "Effects of 588 Mobility and Multihoming on Transport-Layer Security", 589 Security and Privacy 2004, IEEE Symposium , URL http:// 590 research.microsoft.com/users/tuomaura/Publications/ 591 aura-nikander-camarillo-ssp04.pdf, May 2004. 593 Authors' Addresses 595 Randall R. Stewart 596 Cisco Systems, Inc. 597 4785 Forest Drive 598 Suite 200 599 Columbia, SC 29206 600 USA 602 Email: rrs@cisco.com 603 Michael Tuexen 604 Muenster Univ. of Applied Sciences 605 Stegerwaldstr. 39 606 48565 Steinfurt 607 Germany 609 Email: tuexen@fh-muenster.de 611 Gonzalo Camarillo 612 Ericsson 613 Hirsalantie 11 614 Jorvas 02420 615 Finland 617 Email: Gonzalo.Camarillo@ericsson.com 619 Full Copyright Statement 621 Copyright (C) The IETF Trust (2007). 623 This document is subject to the rights, licenses and restrictions 624 contained in BCP 78, and except as set forth therein, the authors 625 retain all their rights. 627 This document and the information contained herein are provided on an 628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 630 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 631 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 632 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 633 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Intellectual Property 637 The IETF takes no position regarding the validity or scope of any 638 Intellectual Property Rights or other rights that might be claimed to 639 pertain to the implementation or use of the technology described in 640 this document or the extent to which any license under such rights 641 might or might not be available; nor does it represent that it has 642 made any independent effort to identify any such rights. Information 643 on the procedures with respect to rights in RFC documents can be 644 found in BCP 78 and BCP 79. 646 Copies of IPR disclosures made to the IETF Secretariat and any 647 assurances of licenses to be made available, or the result of an 648 attempt made to obtain a general license or permission for the use of 649 such proprietary rights by implementers or users of this 650 specification can be obtained from the IETF on-line IPR repository at 651 http://www.ietf.org/ipr. 653 The IETF invites any interested party to bring to its attention any 654 copyrights, patents or patent applications, or other proprietary 655 rights that may cover technology that may be required to implement 656 this standard. Please address the information to the IETF at 657 ietf-ipr@ietf.org. 659 Acknowledgment 661 Funding for the RFC Editor function is provided by the IETF 662 Administrative Support Activity (IASA).