idnits 2.17.1 draft-gont-tcpm-icmp-attacks-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 390), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 2, 2004) is 7207 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 793 (ref. '1') (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-01 == Outdated reference: A later version (-01) exists of draft-poon-tcp-tstamp-mod-00 -- Obsolete informational reference (is this intentional?): RFC 816 (ref. '9') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '10') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2581 (ref. '12') (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '14') (Obsoleted by RFC 4960) == Outdated reference: A later version (-02) exists of draft-gont-tcpm-tcp-soft-errors-00 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) UTN/FRH 4 Internet-Draft August 2, 2004 5 Expires: January 31, 2005 7 ICMP attacks against TCP 8 draft-gont-tcpm-icmp-attacks-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. This document may not be modified, and derivative works of 18 it may not be created, except to publish it as an RFC and to 19 translate it into languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 31, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document discusses the use of the Internet Control Message 46 Protocol (ICMP) to perform a variety of attacks against the 47 Transmission Control Protocol (TCP) and other similar protocols. It 48 proposes a work-around to eliminate or minimize the impact of this 49 type of attack. 51 1. Introduction 53 Recently, awareness has been raised about several threats against the 54 TCP [1] protocol, which include blind connection-reset attacks [5]. 55 These attacks are based on sending forged TCP segments to any of the 56 TCP endpoints, requiring the attacker to be able to guess the 57 four-tuple that identifies the connection to be attacked. 59 While these attacks were known by the research community, they were 60 considered to be unfeasible. Increase in bandwidth availability, and 61 the use of larger TCP windows have made these attacks feasible. 62 Several solutions have been proposed to either eliminate or minimize 63 the impact of these attacks [6][7][8]. 65 However, there is still a possibility for performing a number of 66 attacks against the TCP protocol, which involve the use of ICMP [2]. 67 These attacks include, among others, blind connection-reset attacks. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [3]. 73 2. Background 75 2.1 Internet Control Message Protocol (ICMP) 77 The Internet Control Message Protocol (ICMP) is used by the Internet 78 Architecture to perform the fault-isolation function, that is, the 79 group of actions that hosts and routers take to determine that there 80 is some network failure [9]. 82 In case an intermediate router detects a network problem while trying 83 to forward an IP packet, it will send an ICMP error message to the 84 source host, to raise awareness of the network problem. In the same 85 way, there are a number of cases in which an end-system may generate 86 an ICMP error message when it finds a problem while processing a 87 datagram. 89 The internet header plus the first 64 bits of the packet that 90 elicited the ICMP message are included in the payload of the ICMP 91 error message, so that the receiving host can match the error to the 92 instance of the transport protocol that elicited the error message. 93 Thus, it is assumed that all data needed to identify a transport 94 protocol instance is contained in the first 64 bits of the transport 95 protocol header. 97 When the transport protocol is notified of the error condition, it 98 will perform a fault recovery function. That is, it will try to 99 survive the network failure. 101 In the case of TCP, the fault recovery policy is as follows: 103 o If the network problem being reported is a hard error, abort the 104 corresponding connection. 106 o If the network problem being reported is a soft error, just record 107 this information, and repeatedly retransmit the segment until 108 either it gets acknowledged, or the connection times out. 110 [10] provides information about which ICMP error messages are 111 produced by hosts, intermediate routers, or both. 113 2.2 Handling of ICMP errors 115 The Host Requirements RFC [4] states that a TCP instance should be 116 notified of ICMP error messages received for its corresponding 117 connection. However, neither the Host Requirements RFC nor the 118 original TCP specification recommend any additional security checks 119 on the received ICMP messages. 121 Therefore, as long as the ICMP payload contains the correct 122 four-tuple that identifies the communication instance, it will be 123 processed by the corresponding transport-protocol instance, and the 124 corresponding action will be performed. 126 Thus, an attacker only needs to guess the four-tuple that identifies 127 the communication instance to be attacked, to perform any of the 128 attacks discussed in this document. As discussed in [5], there are a 129 number of scenarios in which an attacker may be able to know or guess 130 this four-tuple. 132 Furthermore, it must be noted that most services use the so-called 133 "well-known" ports, so that only the client port would need to be 134 guessed. In the event that an attacker had no knowledge about the 135 range of port numbers used by clients, this would mean that an 136 attacker would need to send, at most, 65536 packets to perform any of 137 the attacks described in this document. 139 It is clear that additional security checks should be performed on 140 the received ICMP error messages. 142 3. ICMP attacks against TCP 144 ICMP messages can be used to perform a variety of attacks. These 145 attacks have been discussed by the research community to a large 146 extent. 148 Some TCP/IP implementations have added extra security checks on the 149 received ICMP error messages to minimize the impact of these attacks. 150 However, as there has not been any official proposal about what would 151 be the best way to deal with these attacks, these additional security 152 checks have not been widely implemented. 154 The following subsections discuss some of the possible attacks, and 155 propose work-arounds to eliminate or minimize the impact of these 156 attacks. 158 3.1 Blind connection-reset attacks 160 An attacker could use ICMP to perform a blind connection-reset 161 attack. That is, even being off-path, an attacker could reset any 162 TCP connection taking place. In order to perform such an attack, an 163 attacker sends any ICMP error message that indicates a "hard error", 164 to either of the two TCP endpoints of the connection. Because of 165 TCP's fault recovery policy, the connection would be immediately 166 aborted. 168 All an attacker needs to know to perform such an attack is the socket 169 pair that identifies the TCP connection to be attacked. In some 170 scenarios, the IP addresses and port numbers in use may be easily 171 guessed or known to the attacker [5]. 173 There are some points to be considered about this type of attack: 175 o The source address of the ICMP error message need not be forged. 176 Thus, simple egress-filtering based on the source address of IP 177 packets would not serve as a counter-measure against this type of 178 attack. 180 o Even if TCP itself were protected against the blind 181 connection-reset attack described in [5] and [6], this type of 182 attack could still succeed. 184 3.2 Degrading the performance of a connection 186 An attacker could send ICMP Source Quench [2] messages to a TCP 187 endpoint to make it reduce the rate at which it sends data to the 188 other party. While this would not reset the connection, it would 189 certainly degrade the performance of the data transfer taking place 190 over it. 192 4. Constraints in the possible solutions 194 The original ICMP specification [2] requires nodes generating ICMP 195 errors to include the IP header of the packet that elicited the ICMP 196 error message, plus the first 64 bits of its payload, in the payload 197 of the ICMP error message. For TCP, that means that the only fields 198 that will be included are: the source port number, the destination 199 port number, and the 32-bit sequence number. This imposes a 200 constraint on the possible solutions, as there is not much 201 information avalable on which to perform additional security checks. 202 While there exists a proposal to recommend hosts and routers to 203 include more data from the original datagram in the payload of ICMP 204 error messages [11], we cannot yet propose any work-around based on 205 any data past the first 64 bytes of the payload of the original IP 206 datagram that elicited the ICMP error message. 208 5. Solutions to the problem 210 There are a number of counter-measures against this type of attack. 211 Rather than being alternative measures, they could be implemented 212 together to increase the protection against this type of attack. 214 5.1 TCP sequence number checking 216 TCP SHOULD check that the sequence number in the TCP header contained 217 in the payload of the ICMP error message is within the range SND.UNA 218 < SEG.SEQ < SND.NXT. This means that the sequence number should be 219 within the range of the data already sent but not yet acknowledged. 220 If an ICMP error message doesn't pass this check, it SHOULD be 221 discarded. 223 Even if an attacker were able to guess the four-tuple that identifies 224 the TCP connection, this additional check would reduce the 225 possibility of success of the attacker to Flight_Size/2^^32 (where 226 Flight_Size is the number of data bytes already sent to the remote 227 peer, but not yet acknowledged [12]). For a TCP endpoint with no 228 data "in flight", this would completely eliminate the possibility of 229 success of these attack. 231 5.2 Delaying the connection-reset 233 For connections in any of the synchronized states, an additional 234 counter-measure against the blind connection-reset attack could be 235 taken. Rather than immediately aborting a connection, a TCP could 236 abort a connection only after an ICMP error message indicating a hard 237 error has been received a specified number of times, and the 238 corresponding data have already been retransmitted more that some 239 specified number of times. 241 For example, hosts could abort connections only after a fourth ICMP 242 error message (indicating a hard error) is received and the 243 corresponding data have already been retransmitted more than four 244 times. 246 5.3 Port randomization 248 As discussed in the previous sections, in order to perform any of the 249 attack described in this document, an attacker needs to guess (or 250 know) the four-tuple that identifies the connection to be attacked. 251 Randomizing the ephemeral ports used by the clients would reduce the 252 chances of success by an attacker. 254 A proposal exists to enable TCP to reassign a well-known port number 255 to a random value [13]. 257 5.4 Authentication 259 Hosts could require ICMP error messages to be authenticated [10], in 260 order to act upon them. However, while this requirement could make 261 sense for those ICMP error messages sent by hosts, it would not be 262 feasible for those ICMP error messages generated by intermediate 263 routers. 265 [10] contains a discussion on the authentication of ICMP messages. 267 6. Future work 269 The same considerations discussed in this document should be applied 270 to other similar protocols, such as SCTP [14]. 272 7. Security Considerations 274 This document describes the use of ICMP error messages to perform a 275 number of attacks against the TCP protocol, and proposes a number of 276 counter-measures that either eliminate or reduce the impact of these 277 attacks. 279 8. Acknowledgements 281 This document was inspired by Mikka Liljeberg, while discussing some 282 issues related to [15] by private e-mail. The author would like to 283 thank Guillermo Gont and Michael Kerrisk for contributing many 284 valuable comments. 286 9. References 288 9.1 Normative References 290 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 291 September 1981. 293 [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 294 September 1981. 296 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 297 Levels", BCP 14, RFC 2119, March 1997. 299 [4] Braden, R., "Requirements for Internet Hosts - Communication 300 Layers", STD 3, RFC 1122, October 1989. 302 9.2 Informative References 304 [5] Watson, P., "Slipping in the Window: TCP Reset Attacks", 2004 305 CanSecWest Conference , 2004. 307 [6] Stewart, R., "Transmission Control Protocol security 308 considerations", draft-ietf-tcpm-tcpsecure-01 (work in 309 progress), June 2004. 311 [7] Touch, J., "ANONsec: Anonymous IPsec to Defend Against Spoofing 312 Attacks", draft-touch-anonsec-00 (work in progress), May 2004. 314 [8] Poon, K., "Use of TCP timestamp option to defend against blind 315 spoofing attack", draft-poon-tcp-tstamp-mod-00 (work in 316 progress), June 2004. 318 [9] Clark, D., "Fault isolation and recovery", RFC 816, July 1982. 320 [10] Kent, S. and R. Atkinson, "Security Architecture for the 321 Internet Protocol", RFC 2401, November 1998. 323 [11] Gont, F., "Increasing the payload of ICMP error messages", 324 (work in progress) draft-gont-icmp-payload-00.txt, 2004. 326 [12] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 327 Control", RFC 2581, April 1999. 329 [13] Shepard, T., "Reassign Port Number option for TCP", 330 draft-shepard-tcp-reassign-port-number-00 (work in progress), 331 July 2004. 333 [14] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 334 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 335 "Stream Control Transmission Protocol", RFC 2960, October 2000. 337 [15] Gont, F., "TCP's Reaction to Soft Errors", 338 draft-gont-tcpm-tcp-soft-errors-00 (work in progress), June 339 2004. 341 Author's Address 343 Fernando Gont 344 Universidad Tecnologica Nacional 345 Evaristo Carriego 2644 346 Haedo, Provincia de Buenos Aires 1706 347 Argentina 349 Phone: +54 11 4650 8472 350 EMail: fernando@gont.com.ar 352 Intellectual Property Statement 354 The IETF takes no position regarding the validity or scope of any 355 Intellectual Property Rights or other rights that might be claimed to 356 pertain to the implementation or use of the technology described in 357 this document or the extent to which any license under such rights 358 might or might not be available; nor does it represent that it has 359 made any independent effort to identify any such rights. Information 360 on the procedures with respect to rights in RFC documents can be 361 found in BCP 78 and BCP 79. 363 Copies of IPR disclosures made to the IETF Secretariat and any 364 assurances of licenses to be made available, or the result of an 365 attempt made to obtain a general license or permission for the use of 366 such proprietary rights by implementers or users of this 367 specification can be obtained from the IETF on-line IPR repository at 368 http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 this standard. Please address the information to the IETF at 374 ietf-ipr@ietf.org. 376 Disclaimer of Validity 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 381 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 382 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 383 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Copyright Statement 388 Copyright (C) The Internet Society (2004). This document is subject 389 to the rights, licenses and restrictions contained in BCP 78, and 390 except as set forth therein, the authors retain all their rights. 392 Acknowledgment 394 Funding for the RFC Editor function is currently provided by the 395 Internet Society.