idnits 2.17.1 draft-stewart-tsvwg-sctpthreat-01.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 179: '...AT-ACK the random nonce MUST match the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 370 has weird spacing: '...is will again...' -- 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 (September 16, 2004) is 7161 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2960 (ref. '2') (Obsoleted by RFC 4960) Summary: 11 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: March 17, 2005 M. Tuexen 5 Univ. of Applied Sciences Muenster 6 G. Camarillo 7 Ericsson 8 September 16, 2004 10 Stream Control Transmission Protocol (SCTP) Security Threats 11 draft-stewart-tsvwg-sctpthreat-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 17, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 Stream Control Transmission Protocol RFC2960 [2] is a multi-homed 47 transport protocol. As such, unique security threats exists that are 48 addressed in various ways within the protocol itself. This document 49 attempts to detail the known security threats and there 50 countermeasures as detailed in the current version of the SCTP 51 Implementors guide (SCTP-IG). It is hoped that this information will 52 provide some useful background information for many of the newest 53 requirements spelled out in the SCTP-IG. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Address Camping or stealing . . . . . . . . . . . . . . . . . 4 59 2.1 Attack details . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3 Counter measure . . . . . . . . . . . . . . . . . . . . . 5 62 3. Association hijacking 1 . . . . . . . . . . . . . . . . . . . 6 63 3.1 Attack details . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3 Counter measure . . . . . . . . . . . . . . . . . . . . . 7 66 4. Association hijacking 2 . . . . . . . . . . . . . . . . . . . 8 67 4.1 Attack details . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3 Counter measure . . . . . . . . . . . . . . . . . . . . . 8 70 5. Bombing attack (amplification) 1 . . . . . . . . . . . . . . . 9 71 5.1 Attack details . . . . . . . . . . . . . . . . . . . . . . 9 72 5.2 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.3 Counter measure . . . . . . . . . . . . . . . . . . . . . 9 74 6. Bombing attack (amplification) 2 . . . . . . . . . . . . . . . 11 75 6.1 Attack details . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.3 Counter measure . . . . . . . . . . . . . . . . . . . . . 11 78 7. Association redirection . . . . . . . . . . . . . . . . . . . 12 79 7.1 Attack details . . . . . . . . . . . . . . . . . . . . . . 12 80 7.2 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7.3 Counter measure . . . . . . . . . . . . . . . . . . . . . 12 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 84 Intellectual Property and Copyright Statements . . . . . . . . 14 86 1. Introduction 88 Stream Control Transmission Protocol RFC2960 [2] is a multi-homed 89 transport protocol. As such, unique security threats exists that are 90 addressed in various ways within the protocol itself. This document 91 attempts to detail the known security threats and there 92 countermeasures as detailed in the current version of the SCTP 93 Implementors guide (SCTP-IG). It is hoped that this information will 94 provide some useful background information for many of the newest 95 requirements spelled out in the SCTP-IG. 97 This work and some of the changes that went into the tenth version of 98 the SCTP-IG are much indebted to the paper on potential SCTP security 99 risks Effects [1] by Aura, Nikander and Camarillo. Without there 100 work some of these changes would remain undocumented and potential 101 threats. 103 The rest of this document will concentrate on the various attacks 104 that were illustrated in Effects [1] and detail what preventative 105 measures are now in place within the current SCTP standards (if any). 107 2. Address Camping or stealing 109 This attack is a form of denial of service attack crafted around 110 SCTP's multi-homing. In effect an illegitimate endpoint connects to 111 a server and "camps upon" or holds up a valid peers address. This is 112 done to prevent the legitimate peer from communicating with the 113 server. 115 2.1 Attack details 117 +----------+ +----------+ +----------+ 118 | Evil | | Server | | Client | 119 | IP-A=+------------+=IP-X & Y=+-----------+=IP-C & D | 120 | Attacker | | | | Victim | 121 +----------+ +----------+ +----------+ 123 Figure 1: Camping 125 Consider the scenario illustrated in Figure 1. The attacker 126 legitimately holds IP-A and wishes to prevent the 'Client-Victim' 127 from communication with the 'Server'. Note also that both the client 128 and server are multi-homed. The attacker first guesses the port 129 number our client uses in its association attempt. It then uses this 130 port and sets up an association with the server listing not only IP-A 131 but also IP-C as well in its initial INIT chunk. The server will 132 respond and setup the association noting that the attacker is 133 multi-homed holding both IP-A and IP-C. 135 Next the victim sends in an INIT message listing its two valid 136 addresses IP-C and IP-D. In response it will receive an ABORT 137 message with possibly an error code indicating that a new address was 138 added in its attempt to setup an existing association (a restart with 139 new addresses). At this point 'Client-Victim' is now prevented from 140 setting up an association with the server until the server realizes 141 that the attacker does not hold the address IP-C at some future 142 point. 144 2.2 Errata 146 This particular attack was discussed in detail on the SCTP 147 implementors list in March of 2003. Out of that discussion changes 148 were made in the BSD implementation that are now present in the 149 SCTP-IG. In closely examination this attack depends on a number of 150 specific things to occur. 152 1) The attacker must setup the association before the victim and must 153 correctly guess the port number that the victim will use. If the 154 victim uses any other port number the attack will fail. 155 2) SCTP's existing HEARTBEAT mechanism as defined in RFC2960 [2] will 156 eventually catch this situation and abort the evil attackers 157 association. This may take several seconds based on default 158 HEARTBEAT timers but the attacker himself will lose any 159 association. 160 3) If the victim is either not multi-homed, or the address set that 161 it uses is completely camped upon by the attacker (in our example 162 if the attacker had included IP-D in its INIT as well), then the 163 client's INIT message would restart the attackers association 164 destroying it. 166 2.3 Counter measure 168 Version 10 of the SCTP-IG adds a new set of requirements to better 169 counter this attack. In particular the HEARTBEAT mechanism was 170 modified so that addresses unknown to an endpoint (i.e. presented in 171 an INIT with no pre-knowledge given by the application) enter a new 172 state called "UNCONFIRMED". During the time that any address is 173 UNCONFIRMED and yet considered available, heartbeating will be done 174 on those UNCONFIRMED addresses at an accelerated rate. This will 175 lessen the time that an attacker can "camp" on an address. In 176 particular the rate of heartbeats to UNCONFIRMED addresses is done 177 every RTO. Along with this expanded rate of heartbeating, a new 64 178 bit random nonce is required to be inside HEARTBEATs to UNCONFIRMED 179 addresses. In the HEARTBEAT-ACK the random nonce MUST match the 180 value sent in the HEARTBEAT before an address can leave the 181 UNCONFIRMED state. This will prevent an attacker from generating 182 false HEARTBEAT-ACK's with the victims source address(es). 184 3. Association hijacking 1 186 Association hijacking is the ability of some other user to assume the 187 session created by another endpoint. In cases of a true 188 man-in-the-middle only a strong end to end security model can prevent 189 this. However with the addition of the ADD-IP extension to SCTP a 190 endpoint that is NOT a man-in-the-middle may be able to assume 191 another endpoints association. 193 3.1 Attack details 195 The attack is made possible by any mechanism that lets an endpoint 196 acquire some other IP address that was recently in use by an SCTP 197 endpoint. For example in a moble network DHCP may be in use with 198 short IP address lifetimes to reassign IP addresses to migrant hosts. 200 IP-A DHCP-Server's Peer-Server 201 | 202 | 203 1 |-DHCP-Rel(IP-A)---->| 204 2 |------ASCONF(ADD-IP(IP-B), DEL-IP(IP-A)---->XXlost 205 time 206 | 207 |-DHCP-new-net------>| 208 3 |<---Assign (IP-A) 209 | 210 4 |<------------Tag:X-DATA()------------------ 211 | 212 |-------------INIT()------------------------> 213 5 |<------------INIT-ACK()--------------------- 214 | 215 6 |----ASCONF(ADD-IP(IP-Z),DEL-IP(IP-A))------> 217 Figure 2: Association Hijack via DHCP 219 At point 1, our valid client releases the IP address IP-A. It 220 presumably acquires a new address (IP-B) and sends an ASCONF to ADD 221 the new address and delete to old address at point 2, but this packet 222 is lost. Thus our peer (Peer-Server) has no idea that the former 223 peer is no longer at IP-A. Now at point 3 a new "evil" peer DHCP's 224 an address and happens to get the re-assigned address IP-A. Our 225 Peer-Server sends a chunk of DATA at point 4. This reveals to the 226 new owner of IP-A that the former owner of IP-A had an association 227 with Peer-Server. So at point 5 the new owner of IP-A sends an INIT. 228 The INIT-ACK is sent back and inside it is a COOKIE. The cookie 229 would of course hold tie-tags which would list both sets of tags 230 which could then be used at point 6 to add in any other IP addresses 231 that the owner of IP-A holds and thus acquire the association. 233 3.2 Errata 235 This attack depends on a number of events: 237 1) Both endpoints must support the ADD-IP extension. 238 2) One of the endpoints must be using the ADD-IP extension for 239 mobility. 240 3) The IP address must be acquired in such a way as to make the 241 endpoint the owner of that IP address as far as the network is 242 concerned. 243 4) The true peer must not get the ASCONF packet that deletes IP-A and 244 adds its new address to the peer before the new "evil" peer gets 245 control of the association. 246 5) The new "evil" peer must have an alternative address besides IP-A 247 that it can add to the association so it can delete IP-A 248 preventing the real peer from re-acquiring the association when it 249 finally retransmits the ASCONF (from step 2). 251 3.3 Counter measure 253 The latest SCTP-IG adds a new counter measure to this threat. It is 254 now required that Tie-Tags in the State-Cookie parameter not be the 255 actual tags. Instead a new set of two 32 bit nonce must be used to 256 represent the real tags within the association. This prevents the 257 attacker from acquiring the real tags and thus prevents this attack. 259 4. Association hijacking 2 261 Association hijacking is the ability of some other user to assume the 262 session created by another endpoint. In cases where an attacker can 263 take over an IP-address he can easily restart the association. If 264 the peer does not pay attention to the restart notification the 265 attacker has taken over the association. 267 4.1 Attack details 269 Assume that an endpoint E1 having an IP-address A has an SCTP 270 association with endpoint E2. After the attacker has taken over the 271 IP-address A he waits for a packet from E2. After reception of the 272 packet the attacker can perform a full four way handshake using the 273 the IP-addresses and port numbers from the received packet. E2 will 274 consider this as a restart of the association. If and only if the 275 SCTP user of E2 does not process the restart notification the user 276 will not recognize that that association just restarted. From his 277 perspective the association has been hijacked. 279 4.2 Errata 281 This attack depends on a number of circumstances: 283 1) The IP address must be acquired in such a way as to make the evil 284 endpoint the owner of that IP address as far as the network or 285 local lan is concerned. 286 2) The attacker must receive a packet belonging to the association or 287 connection. 288 3) The other endpoints user does not pay attention to restart 289 notifications. 291 4.3 Counter measure 293 It is important to note that this attack is not based on a weakness 294 of the protocol but on the ignorance of the upper layer. This attack 295 is not possible if the upper layer processes the restart 296 notifications provided by SCTP. Note that other IP protocols may 297 also be effected by this attack. 299 5. Bombing attack (amplification) 1 301 The bombing attack is a method to get a server to amplify packets to 302 an innocent victim. 304 5.1 Attack details 306 This attack is performed by setting up an association with a peer and 307 listing the victims IP address in the INIT's list of addresses. 308 After the association is setup, the attacker makes a request for a 309 large data transfer. After making the request the attacker does not 310 acknowledge data sent to it. This then causes the server to 311 re-transmit the data to the alternate address i.e. that of the 312 victim. After waiting an appropriate time period the attacker 313 acknowledges the data for the victim. At some point the attackers 314 address is considered unreachable since only data sent to the victims 315 address is acknowledged. At this point the attacker can send 316 strategic acknowledgments so that the server continues to send data 317 to the victim. 319 5.2 Errata 321 This attack depends on a number of circumstances: 323 1) The victim must NOT support SCTP, otherwise it would respond with 324 an OOTB abort. 325 2) The attacker must time its sending of acknowledgments correctly in 326 order to get its address into the failed state and the victims 327 address as the only valid alternative. 328 3) The attacker must guess TSN values that are accepted by the 329 receiver once the bombing begins since it must acknowledge packets 330 it no longer is seeing. 332 5.3 Counter measure 334 The current SCTP-IG makes two changes to prevent this attack. First 335 it details out proper handling of ICMP messages. With SCTP the ICMP 336 messages provide valuable clues to the SCTP stack that can be 337 verified with the tags for authenticity. Proper handling of an ICMP 338 protocol unreachable (or equivalent) would cause the association 339 setup by the attacker to be immediately failed upon the first 340 retransmission to the victims address. 342 The second change made in the newest SCTP-IG is the requirement that 343 no address that is not CONFIRMED is allowed to have DATA chunks sent 344 to it. This prevents the switch-over to the alternate address from 345 occurring even when ICMP messages are lost in the network and 346 prevents any DATA chunks from being sent to any other destination 347 other then the attacker itself. 349 An SCTP implementation should abort the association if it receives a 350 SACK acknowledging a TSN which has not been sent. This makes TSN 351 guessing for the attacker quite hard because if the attacker 352 acknowledges one TSN too fast the association will be aborted. 354 6. Bombing attack (amplification) 2 356 This attack allows an attacker to use an arbitrary SCTP endpoint to 357 send multiple packets to a victim in response to one packet. 359 6.1 Attack details 361 The attacker sends an INIT listing multiple IP addresses of the 362 victim in the INIT's list of addresses to an arbitrary endpoint. 363 Optionally it request a long cookie life time. Upon reception of the 364 INIT-ACK it stores the cookie and sends it back to the other 365 endpoint. When the other endpoint receives the COOKIE it will send 366 back a COOKIE-ACK to the attacker and up to Max.Burst HEARTBEATS to 367 the victim('s) (to confirm addresses). The victim responds with 368 ABORTs or ICMP messages resulting in the removal of the TCB at the 369 other endpoint. The attacker can now resend the stored cookie as 370 long as it is valid and this will again result in up to Max.Burst 371 HEARTBEATs sent to the victim('s). 373 6.2 Errata 375 The multiplication factor is limited by the number of addresses of 376 the victim and of the end point Max.Burst. Also the shorter the 377 cookie life time is, the earlier the attacker has to go through the 378 initial stage of sending an INIT instead of the just sending the 379 COOKIE. It should also be noted that the attack is more effective if 380 large HEARTBEATs are used for path confirmation. 382 6.3 Counter measure 384 To limit the effectiveness of this attack and end point should 385 1) not allow very large cookie lifetimes, even if they are requested. 386 2) not use larger Max.Burst parameter values than recommended or 387 alternatively only send one CONFIRMATION Heartbeat per RTT. Note 388 that an endpoint may decide to send only one Heartbeat per RTT 389 instead of the maximum (i.e. Max.Burst). An endpoint that 390 chooses this approach will however slow down detection of 391 endpoints camping on valid addresses. 392 3) not use large HEARTBEATs for path confirmation. 394 7. Association redirection 396 This attack allows an attacker to mis-setup an association to a 397 different endpoint. 399 7.1 Attack details 401 The attacker sends an INIT sourced from port 'X' and directed towards 402 port 'Y'. When the INIT-ACK is returned the attacker sends the 403 COOKIE-ECHO chunk and either places a different destination or source 404 port in the SCTP common header i.e. X+1 or Y+1. This then set's up 405 the association with possibly other endpoints. 407 7.2 Errata 409 This attack depends on the failure of an SCTP implementation to store 410 and verify the ports within the COOKIE structure. 412 7.3 Counter measure 414 This attack is easily defeated by an implementation including the 415 ports of both the source and destination within the COOKIE. When the 416 COOKIE is returned if the source and destination ports do not match 417 those within the COOKIE chunk, the SCTP implementation silently 418 discards the invalid COOKIE. 420 8 References 422 [1] Aura, T., Nikander, P. and G. Camarillo, "Effects of Mobility 423 and Multihoming on Transport-Layer Security", December 2003. 425 [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 426 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 427 "Stream Control Transmission Protocol", RFC 2960, October 2000. 429 Authors' Addresses 431 Randall R. Stewart 432 Cisco Systems, Inc. 433 4785 Forest Drive 434 Suite 200 435 Colubmia, SC 29206 436 USA 438 Phone: +1-815-477-2127 439 EMail: rrs@cisco.com 440 Michael Tuexen 441 Univ. of Applied Sciences Muenster 442 Stegerwaldstr. 39 443 48565 Steinfurt 444 Germany 446 EMail: tuexen@fh-muenster.de 448 Gonzalo Camarillo 449 Ericsson 450 Hirsalantie 11 451 Jorvas 02420 452 Finland 454 EMail: Gonzalo.Camarillo@ericsson.com 456 Intellectual Property Statement 458 The IETF takes no position regarding the validity or scope of any 459 Intellectual Property Rights or other rights that might be claimed to 460 pertain to the implementation or use of the technology described in 461 this document or the extent to which any license under such rights 462 might or might not be available; nor does it represent that it has 463 made any independent effort to identify any such rights. Information 464 on the procedures with respect to rights in RFC documents can be 465 found in BCP 78 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of an 469 attempt made to obtain a general license or permission for the use of 470 such proprietary rights by implementers or users of this 471 specification can be obtained from the IETF on-line IPR repository at 472 http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights that may cover technology that may be required to implement 477 this standard. Please address the information to the IETF at 478 ietf-ipr@ietf.org. 480 Disclaimer of Validity 482 This document and the information contained herein are provided on an 483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 485 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 486 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 487 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 490 Copyright Statement 492 Copyright (C) The Internet Society (2004). This document is subject 493 to the rights, licenses and restrictions contained in BCP 78, and 494 except as set forth therein, the authors retain all their rights. 496 Acknowledgment 498 Funding for the RFC Editor function is currently provided by the 499 Internet Society.