idnits 2.17.1 draft-ietf-tcpm-tcpsecure-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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 281. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 297), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 87 has weird spacing: '...more an artif...' -- 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 (April 19, 2004) is 7312 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) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '2') (Obsoleted by RFC 5925) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Stewart 2 Internet-Draft Editor 3 Expires: October 18, 2004 April 19, 2004 5 Transmission Control Protocol security considerations 6 draft-ietf-tcpm-tcpsecure-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 18, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 TCP (RFC793 [1]) is widely deployed and one of the most often used 39 reliable end to end protocols for data communication. Yet when it was 40 defined over 20 years ago the internet, as we know it, was a 41 different place lacking many of the threats that are now common. 42 Recently several rather serious threats have been detailed that can 43 pose new methods for both denial of service and possibly data 44 injection by blind attackers. This document details those threats and 45 also proposes some small changes to the way TCP handles inbound 46 segments that either eliminate the threats or at least minimize them 47 to a more acceptable level. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Blind reset attack using the RST bit . . . . . . . . . . . . . 4 53 2.1 Description of the attack . . . . . . . . . . . . . . . . 4 54 2.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Blind reset attack using the SYN bit . . . . . . . . . . . . . 5 56 3.1 Description of the attack . . . . . . . . . . . . . . . . 5 57 3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Blind data injection attack . . . . . . . . . . . . . . . . . 6 59 4.1 Description of the attack . . . . . . . . . . . . . . . . 6 60 4.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 65 7.2 Informative References . . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . 10 69 1. Introduction 71 TCP (RFC793 [1]) is widely deployed and one of the most often used 72 reliable end to end protocols for data communication. Yet when it was 73 defined over 20 years ago the internet, as we know it, was a 74 different place lacking many of the threats that are now common. 75 Recently several rather serious threats have been detailed that can 76 pose new methods for both denial of service and possibly data 77 injection by blind attackers. This document details those threats and 78 also proposes some small changes to the way TCP handles inbound 79 segments that either eliminate the threats or at least minimize them 80 to a more acceptable level. 82 Most of these changes violate some of the handling procedures for 83 DATA, RST and SYN's as defined in RFC793 [1] but do not cause 84 interoperability issues. The authors feel that many of the changes 85 proposed in this document would, if TCP were being standardized 86 today, be required to be in the base TCP document and the lack of 87 these procedures is more an artifact of the time when TCP was 88 developed than any strict requirement of the protocol. 90 2. Blind reset attack using the RST bit 92 2.1 Description of the attack 94 It has been traditionally thought that for a blind attacker to reset 95 a TCP connection the attacker would have to guess a single sequence 96 number in the TCP sequence space. This would in effect require an 97 attacker to generate (2^^32/2) segments in order to reset a 98 connection. Recent papers have shown this to not necessarily be the 99 case. An attacker need only guess a number that lies between the last 100 sequence number acknowledged and the last sequence number 101 acknowledged added to the receiver window (RCV.WND). Modern operating 102 systems normally default the RCV.WND to about 32,768 bytes. This 103 means that a blind attacker need only guess 65,535 RST segments 104 (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds 105 this means that most connections (assuming the attacker can 106 accurately guess both ports) can be reset in under 200 seconds 107 (usually far less). With the rise of broadband availability and 108 increasing available bandwidth, many Operating Systems have raised 109 their default RCV.WND to as much as 64k, thus making these attacks 110 even easier. 112 2.2 Solution 114 RFC793 [1] currently requires handling of a segment with the RST bit 115 when in a synchronized state to be processed as follows: 116 1) If the RST bit is set and the sequence number is outside the 117 expected window, silently drop the segment. 118 2) If the RST bit is set and the sequence number is acceptable i.e.: 119 (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. 121 Instead, the following changes should be made to provide some 122 protection against such an attack. 123 A) If the RST bit is set and the sequence number is outside the 124 expected window, silently drop the segment. 125 B) If the RST bit is exactly the next expected sequence number, reset 126 the connection. 127 C) If the RST bit is set and the sequence number does not exactly 128 match the next expected sequence value, yet is within the 129 acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an 130 acknowledgment. 132 This solution forms a challenge/response with any RST where the value 133 does not exactly match the expected value and yet the RST is within 134 the window. In cases of a legitimate reset without the exact 135 sequence number, the consequences of this new challenge/response will 136 be that the peer requires an extra round trip time before the 137 connection can be reset. 139 3. Blind reset attack using the SYN bit 141 3.1 Description of the attack 143 The reset attack which uses the RST bit highlights another possible 144 avenue for a blind attacker. Instead of using the RST bit an attacker 145 can use the SYN bit as well to tear down a connection. Using the same 146 guessing technique, repeated SYN's can be generated with sequence 147 numbers incrementing by an amount not larger than the window size 148 apart and thus eventually cause the connection to be terminated. 150 3.2 Solution 152 RFC793 [1] currently requires handling of a segment with the SYN bit 153 set in the synchronized state to be as follows: 154 1) If the SYN bit is set and the sequence number is outside the 155 expected window, send an ACK back to the sender. 156 2) If the SYN bit is set and the sequence number is acceptable i.e.: 157 (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to 158 the peer. 160 Instead, changing the handling of the SYN to the following will 161 provide complete protection from this attack: 162 A) If the SYN bit is set and the sequence number is outside the 163 expected window, send an ACK back to the peer. 164 B) If the SYN bit is set and the sequence number is an exact match to 165 the next expected sequence (RCV.NXT == SEG.SEQ) then send an ACK 166 segment to the peer but before sending the ACK segment subtract 167 one from value being acknowledged. 168 C) If the SYN bit is set and the sequence number is acceptable i.e.: 169 (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) then send an ACK segment to 170 the peer. 172 By always sending an ACK to the sender, a challenge/response is setup 173 with the peer. A legitimate peer, after restart, would not have a TCB 174 in the synchronized state. Thus when the ACK arrives the peer should 175 send a RST segment. Note that for the case of an attacker sending a 176 SYN that exactly matches the RCV.NXT value, by sending a ACK that is 177 less than the RCV.NXT value the true peer will drop the ACK as an old 178 duplicate. In cases where a valid restarting peer picks the ISS 179 number to match the RCV.NXT, sending an ACK value one less than 180 RCV.NXT will cause the restarted peer to see the ACK value as invalid 181 and thus send a RST. 183 4. Blind data injection attack 185 4.1 Description of the attack 187 A third type of attack is also highlighted by both reset attacks. It 188 is quite possible to inject data into a TCP connection by simply 189 guessing a sequence value that is within the window. The ACK value of 190 any data segment is considered valid as long as it does not 191 acknowledge data ahead of the next segment to send. In other words an 192 ACK value is acceptable if it is (SND.UNA-(2^^31-1)) <= SEG.ACK < 193 SND.NXT). This means that an attacker simply need guess two ACK 194 values with every guessed sequence number so that the chances of 195 successfully injecting data into a connection are 1 in ((2^^32/ 196 (RCV.WND * 2)) * (2^^32/(SND.WND * 2))). 198 4.2 Solution 200 An additional input check should be added to any incoming segment. 201 The ACK value should be acceptable only if it is in the range of 202 ((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT). MAX.SND.WND is 203 defined as the largest window that the local receiver has ever 204 advertised to its peer. This window is the scaled value i.e. the 205 value may be larger than 65,535 bytes. This small check will greatly 206 reduce the vulnerability of an attacker guessing a valid sequence 207 number since not only must he/she guess the sequence number in 208 window, but must also guess a proper ack value within a scoped range. 209 This solution reduces but does not eliminate the ability to generate 210 false segments. It does however reduce the probability that invalid 211 data will be injected to a more acceptable level when the maximum 212 send and receive windows do not grow beyond 65,535 bytes. For those 213 applications that wish to close this attack completely RFC2385 [2] 214 should be deployed between the two endpoints. 216 5. Contributors 218 The following people worked under extreme pressure and short notice 219 through the 2003 holiday's to come up with a set of solutions for 220 these attacks. Their contributions and ideas on how to "fix" these 221 TCP weaknesses are inter-mixed with each other to arrive at the set 222 of solutions presented in this document. Shrirang Bage of Cisco 223 Systems, Mark Baushke of Juniper Networks, Mitesh Dalal of Cisco 224 Systems, Frank Kastenholz of Juniper Networks, Amol Khare of Cisco 225 Systems, Qing Li of Wind River Systems Inc., Peter Lei of Cisco 226 Systems, Paul Goyette of Juniper Networks, Patrick Mahan of Cisco 227 Systems, Preety Puri of Wind River Systems Inc., Anantha Ramaiah of 228 Cisco Systems, Art Stine of Juniper Networks, Xiaodan Tang of QNX, 229 and David Wang of Juniper Networks. 231 6. Acknowledgments 233 Special thanks to Damir Rajnovic for suggestions and comments. 235 7. References 237 7.1 Normative References 239 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 240 September 1981. 242 7.2 Informative References 244 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 245 Signature Option", RFC 2385, August 1998. 247 Author's Address 249 Randall R. Stewart 250 Editor 251 8725 West Higgins Road 252 Suite 300 253 Chicago, IL 60631 254 USA 256 Phone: +1-815-477-2127 257 EMail: rrs@cisco.com 259 Intellectual Property Statement 261 The IETF takes no position regarding the validity or scope of any 262 Intellectual Property Rights or other rights that might be claimed to 263 pertain to the implementation or use of the technology described in 264 this document or the extent to which any license under such rights 265 might or might not be available; nor does it represent that it has 266 made any independent effort to identify any such rights. Information 267 on the IETF's procedures with respect to rights in IETF Documents can 268 be found in BCP 78 and BCP 79. 270 Copies of IPR disclosures made to the IETF Secretariat and any 271 assurances of licenses to be made available, or the result of an 272 attempt made to obtain a general license or permission for the use of 273 such proprietary rights by implementers or users of this 274 specification can be obtained from the IETF on-line IPR repository at 275 http://www.ietf.org/ipr. 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights that may cover technology that may be required to implement 280 this standard. Please address the information to the IETF at 281 ietf-ipr@ietf.org. 283 Disclaimer of Validity 285 This document and the information contained herein are provided on an 286 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 287 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 288 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 289 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 290 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 291 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 293 Copyright Statement 295 Copyright (C) The Internet Society (2004). This document is subject 296 to the rights, licenses and restrictions contained in BCP 78, and 297 except as set forth therein, the authors retain all their rights. 299 Acknowledgment 301 Funding for the RFC Editor function is currently provided by the 302 Internet Society.