idnits 2.17.1 draft-gont-tcpm-urgent-data-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 28, 2008) is 5651 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 A. Yourtchenko 5 Intended status: Standards Track Cisco 6 Expires: May 1, 2009 October 28, 2008 8 On the implementation of TCP urgent data 9 draft-gont-tcpm-urgent-data-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 1, 2009. 36 Abstract 38 This document analyzes the current practices for handling TCP urgent 39 data in the current Internet. It describes how popular TCP 40 implementations process urgent data, and also describes how a number 41 of middle-boxes affect how urgent data is processed by end systems. 42 Additionally, it includes a survey of the processing of urgent data 43 by popular TCP implementations. This document updates the relevant 44 specifications such that they accommodate current practice in 45 processing TCP urgent data. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Specification of TCP urgent data . . . . . . . . . . . . . . . 3 51 2.1. Semantics of the Urgent Pointer . . . . . . . . . . . . . 4 52 2.2. Allowed length of urgent data . . . . . . . . . . . . . . 4 53 3. Current implementation practice of TCP urgent data . . . . . . 4 54 3.1. Semantics of the Urgent Pointer . . . . . . . . . . . . . 4 55 3.2. Allowed length of urgent data . . . . . . . . . . . . . . 4 56 4. Updating the specifications to reflect implementations 57 behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Interaction of middle-boxes with urgent data . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Survey of the processing of urgent data by some 66 popular implementations . . . . . . . . . . . . . . . 7 67 A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 A.5. Cisco IOS, versions 12.2(18)SXF7, 12.4(15)T7 . . . . . . . 8 72 A.6. Microsoft Windows 2000, Service Pack 4 . . . . . . . . . . 8 73 A.7. Microsoft Windows 2008 . . . . . . . . . . . . . . . . . . 8 74 A.8. Microsoft Windows 95 . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Intellectual Property and Copyright Statements . . . . . . . . . . 10 78 1. Introduction 80 TCP incorporates a "urgent mechanism" that allows the sending user to 81 stimulate the receiving user to accept some urgent data and to permit 82 the receiving TCP to indicate to the receiving user when all the 83 currently known urgent data has been received by the user. This 84 mechanism permits a point in the data stream to be designated as the 85 end of urgent information. Whenever this point is in advance of the 86 receive sequence number (RCV.NXT) at the receiving TCP, that TCP must 87 tell the user to go into "urgent mode"; when the receive sequence 88 number catches up to the urgent pointer, the TCP must tell user to go 89 into "normal mode". [RFC0793] 91 The URG control flag indicates that the urgent field is meaningful 92 and must be added to the segment sequence number to yield the urgent 93 pointer. The absence of this flag indicates that there is no urgent 94 data outstanding. [RFC0793] 96 The "urgent mechanism" was originally specified in RFC 793 [RFC0793]. 97 Later, RFC 1122 [RFC1122] corrected some errors found in that 98 specification. However, these "corrections" never made into actual 99 implementations, and thus the current specifications do not reflect 100 the way in which virtually all TCP implementations process urgent 101 data. 103 This document analyzes the current practices for handling TCP urgent 104 data in the current Internet. It describes how popular TCP 105 implementations process urgent data, and also describes how a number 106 of middle-boxes affect how urgent data is processed by end systems. 107 Additionally, it includes a survey of the processing of urgent data 108 by popular TCP implementations. This document updates the relevant 109 specifications such that they accommodate current practice in 110 processing TCP urgent data. 112 Section 2 describes what the current IETF secifications state with 113 respect to TCP urgent data. Section 3 describes how current TCP 114 implementations actually process TCP urgent data. Section 4 updates 115 RFC 793 [RFC0793] and RFC 1122 [RFC1122] such that they accommodate 116 current practice in processing TCP urgent data. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2. Specification of TCP urgent data 123 2.1. Semantics of the Urgent Pointer 125 Section 3.1 (page 17) of RFC 793 [RFC0793] originally stated that the 126 Urgent Pointer "communicates the current value of the urgent pointer 127 as a positive offset from the sequence number in this segment. The 128 urgent pointer points to the sequence number of the octet following 129 the urgent data. This field is only be interpreted in segments with 130 the URG control bit set." 132 Section 4.2.2.4 (page 84) of RFC 1122 [RFC1122] "corrects" RFC793 133 stating that "the urgent pointer points to the sequence number of the 134 LAST octet (not LAST+1) in a sequence of urgent data." 136 2.2. Allowed length of urgent data 138 RFC 793 [RFC0793] allows TCP peers to send urgent data of any length. 139 Section 4.2.2.4 (page 84) of RFC 1122 explicitly states that "A TCP 140 MUST support a sequence of urgent data of any length". 142 3. Current implementation practice of TCP urgent data 144 3.1. Semantics of the Urgent Pointer 146 All the popular implementations that the authors of this document 147 have been able to test interpret the semantics of the TCP Urgent 148 Pointer as stated in Section 3.1 of RFC 793. This means that while 149 RFC 1122 officially "corrected" RFC 793, this change has never 150 reflected to become a default behavior in popular TCP 151 implementations. 153 Some operating systems provide a system-wide toggle to override this 154 behavior, and interpret the semantics of the Urgent Pointer as 155 specified in RFC 1122. However, this system-wide toggle has been 156 found to be inconsistent. For example, Linux provides a the sysctl 157 "tcp_stdurg" (e.g., net.ivp4.tcp_stdurg) that, when set, supposedly 158 changes the system behavior to interpret the semantics of the TCP 159 Urgent Pointer as described in RFC 1122. However, this sysctl only 160 changes the semantics of the Urgent Pointer of incoming segments, and 161 not of all segments. This means that if this sysctl is set, the host 162 might be unable to interoperate with itself. 164 3.2. Allowed length of urgent data 166 While Section 4.2.2.4 (page 84) of RFC 1122 explicitly states that "A 167 TCP MUST support a sequence of urgent data of any length", in 168 practice a lot of implementations support only a single byte of 169 urgent data. [UNPv1] 171 4. Updating the specifications to reflect implementations behavior 173 We believe the relevant specifications should be updated to reflect 174 what is the de-facto standard for urgent data: interpret the 175 semantics of the Urgent Pointer as described in RFC 793, and allow 176 only a single byte of urgent data. This has been the behavior 177 implemented by most popular TCP implementations, including the one 178 Linux and in BSD-derived systems. 180 A TCP MUST support a sequence of a single byte urgent data, and MAY 181 support a sequence of urgent data of any length. 183 The TCP Urgent Pointer MUST point to the byte following the last byte 184 of urgent data. 186 (Future revisions of this document will include a list of the 187 specific text in RFC 793 and RFC 1122 that should be "patched" to 188 produce the proposed specification update). 190 5. Interaction of middle-boxes with urgent data 192 As a result of the publication [phrack] Network Intrusion Detection 193 (NIDs) evasion techniques based on urgent data, some middle-boxes 194 modify the TCP data stream such that urgent data is put "in band", 195 that is, they are accessible by the read(2) or recv(2) calls without 196 the MSG_OOB flag. This should probably discourage applications to 197 depend on urgent data for their current operation, as urgent data may 198 not be not reliable in the current Internet. Examples of such 199 middle-boxes are Cisco PIX firewall [Cisco-PIX]. 201 6. Security Considerations 203 Given that there are two different interpretations (RFC793 vs. RFC 204 1122) of semantics of the Urgent Pointer in current implementations, 205 and that either middle-boxes (such as packet scrubbers) or the end- 206 systems themselves could cause the urgent data to be processed "in 207 band", there exists ambiguity in how TCP urgent data sent by a TCP 208 will be processed by the intended recipient. This might make it 209 difficult for a Network Intrusion Detection System (NIDS) to track 210 the application-layer data transferred to the destination system, and 211 thus lead to false negatives or false positives in the NIDS. 212 [CPNI-TCP]. 214 Probably the best way to avoid the security implications of TCP 215 urgent data is to avoid having application protocols depend on the 216 use of TCP urgent data altogether. Packet scrubbers could probably 217 be configured to clear the URG bit, and set the Urgent Pointer to 218 zero. This would basically cause the urgent data to be put "in 219 band". However, this might cause interoperability problems or 220 undesired behavior in the applications running on top of TCP. 222 7. IANA Considerations 224 This document has no actions for IANA. 226 8. Acknowledgements 228 The authors of this document would like to thank Carlos Pignataro, 229 Anantha Ramaiah and Dan Wing for providing valuable feedback on an 230 earlier version of this document. 232 9. References 234 9.1. Normative References 236 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 237 RFC 793, September 1981. 239 [RFC1122] Braden, R., "Requirements for Internet Hosts - 240 Communication Layers", STD 3, RFC 1122, October 1989. 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 9.2. Informative References 247 [CPNI-TCP] 248 CPNI, "Security Assessment of the Transmission Control 249 Protocol (TCP)", (to be published) . 251 [Cisco-PIX] 252 Cisco PIX, "http://www.cisco.com/en/US/docs/security/asa/ 253 asa70/command/reference/tz.html#wp1288756". 255 [FreeBSD] The FreeBSD project, "http://www.freebsd.org". 257 [Linux] The Linux Project, "http://www.kernel.org". 259 [NetBSD] The NetBSD project, "http://www.netbsd.org". 261 [OpenBSD] The OpenBSD project, "http://www.openbsd.org". 263 [UNPv1] Stevens, W., "UNIX Network Programming, Volume 1. 264 Networking APIs: Sockets and XTI", Prentice Hall PTR , 265 1997. 267 [Windows2000] 268 Microsoft Windows 2000, "http://technet.microsoft.com/ 269 en-us/library/bb726981(printer).aspx". 271 [Windows95] 272 Microsoft Windows 95, 273 "ftp://ftp.demon.co.uk/pub/mirrors/win95netfaq/ 274 faq-c.html". 276 [phrack] Ko, Y., Ko, S., and M. Ko, "NIDS Evasion Method named 277 "SeolMa"", Phrack Magazine, Volume 0x0b, Issue 0x39, Phile 278 #0x03 of 0x12 http://www.phrack.org/ 279 issues.html?issue=57&id=3#article, 2001. 281 Appendix A. Survey of the processing of urgent data by some popular 282 implementations 284 A.1. FreeBSD 286 FreeBSD [FreeBSD] interprets the semantics of the urgent pointer as 287 specified in RFC 793. It does not provide any sysctl to override 288 this behavior. However, it provides the SO_OOBINLINE that when set 289 causes TCP urgent data to be put "in band". That is, it will be 290 accessible by the read(2) or recv(2) calls without the MSG_OOB flag. 292 FreeBSD supports only one byte of urgent data. That is, only the 293 byte preceding the Urgent Pointer is considered as "urgent data". 295 A.2. Linux 297 Linux [Linux] interprets the semantics of the urgent pointer as 298 specified in RFC 793. It provides the net.ipv4.tcp_stdurg sysctl to 299 override this behavior to interpret the Urgent Pointer as specified 300 by RFC 1122. However, this sysctl only affects the processing of 301 incoming segments (the Urgent Pointer in outgoing segments will still 302 be set as specified in RFC 793). 304 Linux supports only one byte of urgent data. That is, only the byte 305 preceding the Urgent Pointer is considered as "urgent data". 307 A.3. NetBSD 309 NetBSD [NetBSD] interprets the semantics of the urgent pointer as 310 specified in RFC 793. It does not provide any sysctl to override 311 this behavior. However, it provides the SO_OOBINLINE that when set 312 causes TCP urgent data to be put "in band". That is, it will be 313 accessible by the read(2) or recv(2) calls without the MSG_OOB flag. 315 NetBSD supports only one byte of urgent data. That is, only the byte 316 preceding the Urgent Pointer is considered as "urgent data". 318 A.4. OpenBSD 320 OpenBSD [OpenBSD] interprets the semantics of the urgent pointer as 321 specified in RFC 793. It does not provide any sysctl to override 322 this behavior. However, it provides the SO_OOBINLINE that when set 323 causes TCP urgent data to be put "in band". That is, it will be 324 accessible by the read(2) or recv(2) calls without the MSG_OOB flag. 326 OpenBSD supports only one byte of urgent data. That is, only the 327 byte preceding the Urgent Pointer is considered as "urgent data". 329 A.5. Cisco IOS, versions 12.2(18)SXF7, 12.4(15)T7 331 Cisco IOS, versions 12.2(18)SXF7, 12.4(15)T7 interpret the semantics 332 of the urgent pointer as specified in RFC 793. However, tests 333 performed with an HTTP server running on Cisco IOS version 334 12.2(18)SXF7 and 12.4(15)T7 suggest that urgent data is processed "in 335 band". That is, they are accessible together with "normal" data. 336 The TCP debugs on the Cisco IOS device do explicitly mention the 337 presence of urgent data, and thus we infer that the behavior is 338 different depending on the application. 340 A.6. Microsoft Windows 2000, Service Pack 4 342 Microsoft Windows 2000 [Windows2000] interprets the semantics of the 343 urgent pointer as specified in RFC 793. It provides the 344 TcpUseRFC1122UrgentPointer system-wide variable to override this 345 behavior to interpret the Urgent Pointer as specified by RFC 1122. 346 However, the tests performed with the sample server application 347 compiled using the cygwin environment, has shown that the default 348 behavior is to return the urgent data "in band". 350 A.7. Microsoft Windows 2008 352 Microsoft Windows 2008 interprets the semantics of the urgent pointer 353 as specified in RFC 793. 355 A.8. Microsoft Windows 95 357 Microsoft Windows 95 interprets the semantics of the urgent pointer 358 as specified in RFC 793. It provides the BSDUrgent system-wide 359 variable to override this behavior to interpret the Urgent Pointer as 360 specified by RFC 1122. Windows 95 supports only one byte of urgent 361 data. That is, only the byte preceding the Urgent Pointer is 362 considered as "urgent data". [Windows95] 364 Authors' Addresses 366 Fernando Gont 367 Universidad Tecnologica Nacional / Facultad Regional Haedo 368 Evaristo Carriego 2644 369 Haedo, Provincia de Buenos Aires 1706 370 Argentina 372 Phone: +54 11 4650 8472 373 Email: fernando@gont.com.ar 374 URI: http://www.gont.com.ar 376 Andrew Yourtchenko 377 Cisco 378 De Kleetlaan, 7 379 Diegem B-1831 380 Belgium 382 Phone: +32 2 704 5494 383 Email: ayourtch@cisco.com 385 Full Copyright Statement 387 Copyright (C) The IETF Trust (2008). 389 This document is subject to the rights, licenses and restrictions 390 contained in BCP 78, and except as set forth therein, the authors 391 retain all their rights. 393 This document and the information contained herein are provided on an 394 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 395 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 396 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 397 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 398 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 399 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 401 Intellectual Property 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org.