From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6093.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc6093.txt (limited to 'doc/rfc/rfc6093.txt') diff --git a/doc/rfc/rfc6093.txt b/doc/rfc/rfc6093.txt new file mode 100644 index 0000000..36a16d2 --- /dev/null +++ b/doc/rfc/rfc6093.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Gont +Request for Comments: 6093 UTN/FRH +Updates: 793, 1011, 1122 A. Yourtchenko +Category: Standards Track Cisco +ISSN: 2070-1721 January 2011 + + + On the Implementation of the TCP Urgent Mechanism + +Abstract + + This document analyzes how current TCP implementations process TCP + urgent indications and how the behavior of some widely deployed + middleboxes affects how end systems process urgent indications. This + document updates the relevant specifications such that they + accommodate current practice in processing TCP urgent indications, + raises awareness about the reliability of TCP urgent indications in + the Internet, and recommends against the use of urgent indications + (but provides advice to applications that do). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6093. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Gont & Yourtchenko Standards Track [Page 1] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Specification of the TCP Urgent Mechanism .......................3 + 2.1. Semantics of Urgent Indications ............................3 + 2.2. Semantics of the Urgent Pointer ............................4 + 2.3. Allowed Length of "Urgent Data" ............................4 + 3. Current Implementation Practice of the TCP Urgent Mechanism .....5 + 3.1. Semantics of Urgent Indications ............................5 + 3.2. Semantics of the Urgent Pointer ............................5 + 3.3. Allowed Length of "Urgent Data" ............................6 + 3.4. Interaction of Middleboxes with TCP Urgent Indications .....6 + 4. Updating RFC 793, RFC 1011, and RFC 1122 ........................6 + 5. Advice to New Applications Employing TCP ........................7 + 6. Advice to Applications That Make Use of the Urgent Mechanism ....7 + 7. Security Considerations .........................................7 + 8. Acknowledgements ................................................8 + 9. References ......................................................8 + 9.1. Normative References .......................................8 + 9.2. Informative References .....................................8 + Appendix A. Survey of the Processing of TCP Urgent + Indications by Some Popular TCP Implementations ......10 + A.1. FreeBSD ...................................................10 + A.2. Linux .....................................................10 + A.3. NetBSD ....................................................10 + A.4. OpenBSD ...................................................11 + A.5. Cisco IOS software ........................................11 + A.6. Microsoft Windows 2000, Service Pack 4 ....................11 + A.7. Microsoft Windows 2008 ....................................11 + A.8. Microsoft Windows 95 ......................................11 + + + + + + + + + + + + + + + + + + + + + +Gont & Yourtchenko Standards Track [Page 2] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + +1. Introduction + + This document analyzes how some current TCP implementations process + TCP urgent indications, and how the behavior of some widely deployed + middleboxes affects the processing of urgent indications by hosts. + This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC + 1122 [RFC1122] such that they accommodate current practice in + processing TCP urgent indications. It also provides advice to + applications using the urgent mechanism and raises awareness about + the reliability of TCP urgent indications in the current Internet. + + Given the above issues and potential interoperability issues with + respect to the currently common default mode operation, it is + strongly recommended that applications do not employ urgent + indications. Nevertheless, urgent indications are still retained as + a mandatory part of the TCP protocol to support the few legacy + applications that employ them. However, it is expected that even + these applications will have difficulties in environments with + middleboxes. + + Section 2 describes what the current IETF specifications state with + respect to TCP urgent indications. Section 3 describes how current + TCP implementations actually process TCP urgent indications. Section + 4 updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 + [RFC1122], such that they accommodate current practice in processing + TCP urgent indications. Section 5 provides advice to new + applications employing TCP, with respect to the TCP urgent mechanism. + Section 6 provides advice to existing applications that use or rely + on the TCP urgent mechanism. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Specification of the TCP Urgent Mechanism + +2.1. Semantics of Urgent Indications + + TCP implements an "urgent mechanism" that allows the sending user to + stimulate the receiving user to accept some "urgent data" and that + permits the receiving TCP to indicate to the receiving user when all + the currently known "urgent data" have been read. + + The TCP urgent mechanism permits a point in the data stream to be + designated as the end of urgent information. Whenever this point is + in advance of the receive sequence number (RCV.NXT) at the receiving + TCP, that TCP must tell the user to go into "urgent mode"; when the + receive sequence number catches up to the urgent pointer, the TCP + + + +Gont & Yourtchenko Standards Track [Page 3] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + + must tell user to go into "normal mode" [RFC0793]. This means, for + example, that data that was received as "normal data" might become + "urgent data" if an urgent indication is received in some successive + TCP segment before that data is consumed by the TCP user. + + The URG control flag indicates that the "Urgent Pointer" field is + meaningful and must be added to the segment sequence number to yield + the urgent pointer. The absence of this flag indicates that there is + no "urgent data" outstanding [RFC0793]. + + The TCP urgent mechanism is NOT a mechanism for sending "out-of-band" + data: the so-called "urgent data" should be delivered "in-line" to + the TCP user. + +2.2. Semantics of the Urgent Pointer + + There is some ambiguity in RFC 793 [RFC0793] with respect to the + semantics of the Urgent Pointer. Section 3.1 (page 17) of RFC 793 + [RFC0793] states that the Urgent Pointer "communicates the current + value of the urgent pointer as a positive offset from the sequence + number in this segment. The urgent pointer points to the sequence + number of the octet following the urgent data. This field is only be + interpreted in segments with the URG control bit set" (sic). + However, Section 3.9 (page 56) of RFC 793 [RFC0793] states, when + describing the processing of the SEND call in the ESTABLISHED and + CLOSE-WAIT states, that "If the urgent flag is set, then SND.UP <- + SND.NXT-1 and set the urgent pointer in the outgoing segments". + + RFC 1011 [RFC1011] clarified this ambiguity in RFC 793 stating that + "Page 17 is wrong. The urgent pointer points to the last octet of + urgent data (not to the first octet of non-urgent data)". RFC 1122 + [RFC1122] formally updated RFC 793 by stating, in Section 4.2.2.4 + (page 84), that "the urgent pointer points to the sequence number of + the LAST octet (not LAST+1) in a sequence of urgent data". + +2.3. Allowed Length of "Urgent Data" + + RFC 793 [RFC0793] allows TCP peers to send "urgent data" of any + length, as the TCP urgent mechanism simply provides a pointer to an + interesting point in the data stream. In this respect, Section + 4.2.2.4 (page 84) of RFC 1122 [RFC1122] explicitly states that "A TCP + MUST support a sequence of urgent data of any length". + + + + + + + + + +Gont & Yourtchenko Standards Track [Page 4] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + +3. Current Implementation Practice of the TCP Urgent Mechanism + +3.1. Semantics of Urgent Indications + + As discussed in Section 2, the TCP urgent mechanism simply permits a + point in the data stream to be designated as the end of urgent + information but does NOT provide a mechanism for sending "out-of- + band" data. + + Unfortunately, virtually all TCP implementations process TCP urgent + indications differently. By default, the last byte of "urgent data" + is delivered "out of band" to the application. That is, it is not + delivered as part of the normal data stream [UNPv1]. For example, + the "out-of-band" byte is read by an application when a recv(2) + system call with the MSG_OOB flag set is issued. + + Most implementations provide a socket option (SO_OOBINLINE) that + allows an application to override the (broken) default processing of + urgent indications, so that "urgent data" is delivered "in line" to + the application, thus providing the semantics intended by the IETF + specifications. + +3.2. Semantics of the Urgent Pointer + + All the popular implementations that the authors of this document + have been able to test interpret the semantics of the TCP Urgent + Pointer as specified in Section 3.1 of RFC 793. This means that even + when RFC 1122 formally updated RFC 793 to clarify the ambiguity in + the semantics of the Urgent Pointer, this clarification was never + reflected in actual implementations (i.e., virtually all + implementations default to the semantics of the urgent pointer + specified in Section 3.1 of RFC 793). + + Some operating systems provide a system-wide toggle to override this + behavior and interpret the semantics of the Urgent Pointer as + clarified in RFC 1122. However, this system-wide toggle has been + found to be inconsistent. For example, Linux provides the sysctl + "tcp_stdurg" (i.e., net.ipv4.tcp_stdurg) that, when set, supposedly + changes the system behavior to interpret the semantics of the TCP + Urgent Pointer as specified in RFC 1122. However, this sysctl changes + the semantics of the Urgent Pointer only for incoming segments (i.e., + not for outgoing segments). This means that if this sysctl is set, + an application might be unable to interoperate with itself if both + the TCP sender and the TCP receiver are running on the same host. + + + + + + + +Gont & Yourtchenko Standards Track [Page 5] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + +3.3. Allowed Length of "Urgent Data" + + While Section 4.2.2.4 (page 84) of RFC 1122 explicitly states that "A + TCP MUST support a sequence of urgent data of any length", in + practice, all those implementations that interpret TCP urgent + indications as a mechanism for sending "out-of-band" data keep a + buffer of a single byte for storing the "last byte of urgent data". + Thus, if successive indications of "urgent data" are received before + the application reads the pending "out-of-band" byte, that pending + byte will be discarded (i.e., overwritten by the new byte of "urgent + data"). + + In order to avoid "urgent data" from being discarded, some + implementations queue each of the received "urgent bytes", so that + even if another urgent indication is received before the pending + "urgent data" are consumed by the application, those bytes do not + need to be discarded. Some of these implementations have been known + to fail to enforce any limits on the amount of "urgent data" that + they queue; thus, they become vulnerable to trivial resource + exhaustion attacks [CPNI-TCP]. + + It should be reinforced that the aforementioned implementations are + broken. The TCP urgent mechanism is not a mechanism for delivering + "out-of-band" data. + +3.4. Interaction of Middleboxes with TCP Urgent Indications + + As a result of the publication of Network Intrusion Detection System + (NIDS) evasion techniques based on TCP urgent indications [phrack], + some middleboxes clear the urgent indications by clearing the URG + flag and setting the Urgent Pointer to zero. This causes the "urgent + data" to become "in line" (that is, accessible by the read(2) call or + the recv(2) call without the MSG_OOB flag) in the case of those TCP + implementations that interpret the TCP urgent mechanism as a facility + for delivering "out-of-band" data (as described in Section 3.1). An + example of such a middlebox is the Cisco PIX firewall [Cisco-PIX]. + This should discourage applications from depending on urgent + indications for their correct operation, as urgent indications may + not be reliable in the current Internet. + +4. Updating RFC 793, RFC 1011, and RFC 1122 + + Considering that as long as both the TCP sender and the TCP receiver + implement the same semantics for the Urgent Pointer there is no + functional difference in having the Urgent Pointer point to "the + sequence number of the octet following the urgent data" vs. "the + last octet of urgent data", and that all known implementations + interpret the semantics of the Urgent Pointer as pointing to "the + + + +Gont & Yourtchenko Standards Track [Page 6] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + + sequence number of the octet following the urgent data", we hereby + update RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 [RFC1122] + such that "the urgent pointer points to the sequence number of the + octet following the urgent data" (in segments with the URG control + bit set), thus accommodating virtually all existing TCP + implementations. + +5. Advice to New Applications Employing TCP + + As a result of the issues discussed in Section 3.2 and Section 3.4, + new applications SHOULD NOT employ the TCP urgent mechanism. + However, TCP implementations MUST still include support for the + urgent mechanism such that existing applications can still use it. + +6. Advice to Applications That Make Use of the Urgent Mechanism + + Even though applications SHOULD NOT employ the urgent mechanism, + applications that still decide to employ it MUST set the SO_OOBINLINE + socket option, such that "urgent data" is delivered in line, as + intended by the IETF specifications. + + Additionally, applications that still decide to use the urgent + mechanism need to be designed for correct operation even when the URG + flag is cleared by middleboxes. + +7. Security Considerations + + Multiple factors can affect the data flow that is actually delivered + to an application when the TCP urgent mechanism is employed: for + example, the two possible interpretations of the semantics of the + Urgent Pointer in current implementations (e.g., depending on the + value of the tcp_stdurg sysctl), the possible implementation of the + urgent mechanism as an "out-of-band" (OOB) facility (versus "in-band" + as intended by the IETF specifications), or middleboxes (such as + packet scrubbers) or the end-systems themselves that could cause the + "urgent data" to be processed "in line". This might make it + difficult for a Network Intrusion Detection System (NIDS) to track + the application-layer data transferred to the destination system and + thus lead to false negatives or false positives in the NIDS + [CPNI-TCP] [phrack]. + + Probably the best way to avoid the security implications of TCP + "urgent data" is to avoid having applications use the TCP urgent + mechanism altogether. Packet scrubbers could probably be configured + to clear the URG bit and set the Urgent Pointer to zero. This would + basically cause the "urgent data" to be put "in line". However, this + + + + + +Gont & Yourtchenko Standards Track [Page 7] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + + might cause interoperability problems or undesired behavior in those + applications that rely on the TCP urgent mechanism, such as Telnet + [RFC0854] and FTP [RFC0959]. + +8. Acknowledgements + + The authors of this document would like to thank (in alphabetical + order) Jari Arkko, Ron Bonica, David Borman, Dave Cridland, Ralph + Droms, Wesley Eddy, John Heffner, Alfred Hoenes, Alexey Melnikov, + Keith Moore, Carlos Pignataro, Tim Polk, Anantha Ramaiah, Joe Touch, + Michael Welzl, Dan Wing, and Alexander Zimmermann for providing + valuable feedback on earlier versions of this document. + + Fernando would like to thank David Borman and Joe Touch for a + fruitful discussion about the TCP urgent mechanism at IETF 73 + (Minneapolis). + + Fernando Gont's attendance to IETF meetings was supported by ISOC's + "Fellowship to the IETF" program. + + Finally, Fernando Gont wishes to express deep and heartfelt gratitude + to Jorge Oscar Gont and Nelida Garcia for their precious motivation + and guidance. + +9. References + +9.1. Normative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC1011] Reynolds, J. and J. Postel, "Official Internet + protocols", RFC 1011, May 1987. + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +9.2. Informative References + + [CPNI-TCP] Gont, F., "Security Assessment of the Transmission + Control Protocol (TCP)", "http://www.cpni.gov.uk/ + Docs/tn-03-09-security-assessment-TCP.pdf", 2009. + + [Cisco-PIX] Cisco PIX, "http://www.cisco.com/en/US/docs/security/ + asa/asa70/command/reference/tz.html#wp1288756". + + + +Gont & Yourtchenko Standards Track [Page 8] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + + [FreeBSD] The FreeBSD project, "http://www.freebsd.org". + + [Linux] The Linux Project, "http://www.kernel.org". + + [NetBSD] The NetBSD project, "http://www.netbsd.org". + + [OpenBSD] The OpenBSD project, "http://www.openbsd.org". + + [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol + Specification", STD 8, RFC 854, May 1983. + + [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, October 1985. + + [UNPv1] Stevens, W., "UNIX Network Programming, Volume 1. + Networking APIs: Sockets and XTI", Prentice Hall PTR, + 1997. + + [Windows2000] Microsoft Windows 2000, "http://technet.microsoft.com/ + en-us/library/bb726981(printer).aspx". + + [Windows95] Microsoft Windows 95, "ftp://ftp.demon.co.uk/pub/ + mirrors/win95netfaq/faq-c.html". + + [phrack] Ko, Y., Ko, S., and M. Ko, "NIDS Evasion Method named + "SeolMa"", Phrack Magazine, Volume 0x0b, Issue 0x39, + Phile #0x03 of 0x12 http://www.phrack.org/ + issues.html?issue=57&id=3#article, 2001. + + + + + + + + + + + + + + + + + + + + + + + +Gont & Yourtchenko Standards Track [Page 9] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + +Appendix A. Survey of the Processing of TCP Urgent Indications by Some + Popular TCP Implementations + +A.1. FreeBSD + + FreeBSD 8.0 [FreeBSD] interprets the semantics of the urgent pointer + as specified in Section 4 of this document. It does not provide any + sysctl to override this behavior. + + FreeBSD provides the SO_OOBINLINE socket option that, when set, + causes TCP "urgent data" to remain "in line". That is, it will be + accessible by the read(2) call or the recv(2) call without the + MSG_OOB flag. + + FreeBSD supports only one byte of "urgent data". That is, only the + byte preceding the Urgent Pointer is considered "urgent data". + +A.2. Linux + + Linux 2.6.15-53-386 [Linux] interprets the semantics of the urgent + pointer as specified in Section 4 of this document. It provides the + net.ipv4.tcp_stdurg sysctl to override this behavior to interpret the + Urgent Pointer as specified in RFC 1122 [RFC1122]. However, this + sysctl only affects the processing of incoming segments (the Urgent + Pointer in outgoing segments will still be set as specified in + Section 4 of this document). + + Linux provides the SO_OOBINLINE socket option that, when set, causes + TCP "urgent data" to remain "in line". That is, it will be + accessible by the read(2) call or the recv(2) call without the + MSG_OOB flag. + + Linux supports only one byte of "urgent data". That is, only the + byte preceding the Urgent Pointer is considered "urgent data". + +A.3. NetBSD + + NetBSD 5.0.1 [NetBSD] interprets the semantics of the urgent pointer + as specified in Section 4 of this document. It does not provide any + sysctl to override this behavior. + + NetBSD provides the SO_OOBINLINE socket option that, when set, causes + TCP "urgent data" to remain "in line". That is, it will be + accessible by the read(2) call or the recv(2) call without the + MSG_OOB flag. + + NetBSD supports only one byte of "urgent data". That is, only the + byte preceding the Urgent Pointer is considered "urgent data". + + + +Gont & Yourtchenko Standards Track [Page 10] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + +A.4. OpenBSD + + OpenBSD 4.2 [OpenBSD] interprets the semantics of the urgent pointer + as specified in Section 4 of this document. It does not provide any + sysctl to override this behavior. + + OpenBSD provides the SO_OOBINLINE socket option that, when set, + causes TCP "urgent data" to remain "in line". That is, it will be + accessible by the read(2) or recv(2) calls without the MSG_OOB flag. + + OpenBSD supports only one byte of "urgent data". That is, only the + byte preceding the Urgent Pointer is considered "urgent data". + +A.5. Cisco IOS software + + Cisco IOS Software Releases 12.2(18)SXF7, 12.4(15)T7 interpret the + semantics of the urgent pointer as specified in Section 4 of this + document. + + The behavior is consistent with having the SO_OOBINLINE socket option + turned on, i.e., the data is processed "in line". + +A.6. Microsoft Windows 2000, Service Pack 4 + + Microsoft Windows 2000 [Windows2000] interprets the semantics of the + urgent pointer as specified in Section 4 of this document. It + provides the TcpUseRFC1122UrgentPointer system-wide variable to + override this behavior, interpreting the Urgent Pointer as specified + in RFC 1122 [RFC1122]. + + Tests performed with a sample server application compiled using the + cygwin environment has shown that the default behavior is to return + the "urgent data" "in line". + +A.7. Microsoft Windows 2008 + + Microsoft Windows 2008 interprets the semantics of the urgent pointer + as specified in Section 4 of this document. + +A.8. Microsoft Windows 95 + + Microsoft Windows 95 interprets the semantics of the urgent pointer + as specified in Section 4 of this document. It provides the + BSDUrgent system-wide variable to override this behavior, + interpreting the Urgent Pointer as specified in RFC 1122 [RFC1122]. + Windows 95 supports only one byte of "urgent data". That is, only + the byte preceding the Urgent Pointer is considered "urgent data" + [Windows95]. + + + +Gont & Yourtchenko Standards Track [Page 11] + +RFC 6093 On the TCP Urgent Mechanism January 2011 + + +Authors' Addresses + + Fernando Gont + Universidad Tecnologica Nacional / Facultad Regional Haedo + Evaristo Carriego 2644 + Haedo, Provincia de Buenos Aires 1706 + Argentina + + Phone: +54 11 4650 8472 + EMail: fernando@gont.com.ar + URI: http://www.gont.com.ar + + + Andrew Yourtchenko + Cisco + De Kleetlaan, 7 + Diegem B-1831 + Belgium + + Phone: +32 2 704 5494 + EMail: ayourtch@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gont & Yourtchenko Standards Track [Page 12] + -- cgit v1.2.3