RFC 6429

TCP Sender Clarification for Persist Condition

📅 published December 2011, from ietf

TCP Sender Clarification for Persist Condition ✨

Internet Engineering Task Force (IETF) 🌸 This one is from the IETF stream.

RFC 6429 💖 That's the number, and it's the RFC's own number. It's published under the Informational category, so it's for information, not a Standards Track spec. The ISSN is 2070-1721, and the date is December 2011.

The authors are M. Bashyam (Ocarina Networks, Inc.), M. Jethanandani, and A. Ramaiah (Cisco). The title block doesn't list any obsoletes or updates, so this RFC doesn't claim to replace or update any other RFC. 🦋

Abstract 📝

Okay so this doc clarifies the Zero Window Probes (ZWPs) from RFC 1122 ("Requirements for Internet Hosts -- Communication Layers") 🧚 It's specifically about what you're allowed to do to connections that are stuck in the ZWP condition. And here's the tea: it's not changing the standard. It's clearing up a misinterpretation of RFC 1122 that people have been running with until now. 💅

Status of This Memo 🎀

This document is not an Internet Standards Track specification. It's published just for information, bestie.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). But not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that. 🌈

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6429. ✨

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) as they are in effect on the date this document was published. Please actually read these docs carefully, because they spell out your rights and restrictions for this document. 🫶 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 🗺️

1. Introduction ....................................................2
   1.1. Requirements Language ......................................3
2. Discussion of RFC 1122 Requirement ..............................3
3. Description of One Simple Attack ................................4
4. Clarification Regarding RFC 1122 Requirements ...................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................5
7. References ......................................................6
   7.1. Normative References .......................................6
   7.2. Informative References .....................................6

1. Introduction 🌟

Okay, so Section 4.2.2.17 of "Requirements for Internet Hosts -- Communication Layers" [RFC1122] says this:

"A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. DISCUSSION: It is extremely important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP".

So zero window probing needs to exist, or a connection could hang forever if the ACK segments that reopen the window get lost. 😭 The state where the sender goes into Zero Window Probe (ZWP) mode is usually called the 'persist condition'. 🍓

This guidance isn't meant to stop the operating system or an application from doing resource management. They can ask for connections to be aborted no matter whether those connections are in the persist condition or not. The TCP implementation needs to comply and abort those connections. 💪 But if that resource management doesn't happen outside the protocol implementation, then TCP implementations that misread Section 4.2.2.17 of [RFC1122] could make systems vulnerable to denial-of-service (DoS) [RFC4732] scenarios, where attackers tie up resources by keeping connections in the persist condition. 🙈 That's giving danger.

Rather than changing the standard, this document clarifies what has been, until now, a misinterpretation of the standard as specified in RFC 1122 [RFC1122]. ✨

Section 2 of this document explains why implementations might not close connections just because they're in the persist condition, but still need to let those connections be closed on command. Section 3 outlines a simple attack on systems that don't manage connections in this state well enough. Section 4 wraps up with a requirements-language clarification to the RFC 1122 requirement. 🎀

1.1. Requirements Language 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🧠

2. Discussion of RFC 1122 Requirement 💭

Per [RFC1122], as long as ACKs are being received for window probes, a connection can keep sitting in the persist condition. This is an important feature 🫶 because applications usually want the TCP connection to stay open unless an application explicitly closes it.

Here's an example: say a user is running a network print job, and the printer runs out of paper and is waiting for the user to reload the paper tray (that's user intervention). 🖨️ During all this, the printer might not be reading data from the printing application. 🥲

Yes, this might cause a long ZWP state. But it would be premature for TCP to take action on its own and close the printer connection just because nothing is progressing. Once the printer's paper tray is reloaded (which could take minutes, hours, or even days), the print job needs to be able to continue, uninterrupted, over the same TCP connection. 👑

Now here's where it gets sketchy. Systems that misread Section 4.2.2.17 of [RFC1122] might get hit by DoS attacks, because they don't have enough mechanisms to release system resources that are tied up by connections in the persist condition when resources are running out. 😬 For example, picture a busy server where multiple (attacker) clients can advertise a zero window forever by reliably acknowledging the ZWPs. That could eventually lead to resource exhaustion on the server. In that case, the application or operating system would need to take appropriate action on the TCP connection to reclaim its resources and keep serving legitimate connections. 💅

This problem applies to TCP and to TCP-derived flow-controlled transport protocols, like the Stream Control Transmission Protocol (SCTP). 🧚

Clearly, a system needs to be robust against these attacks and let connections in the persist condition be aborted the same way as any other connection. Section 4 of this document provides the clarification needed to allow that kind of resource management. 🌈

3. Description of One Simple Attack 🕵️‍♀️

To show what a potential DoS scenario looks like, imagine lots of client applications opening TCP connections with an HTTP [RFC2616] server. Each one sends a GET request for a large page and then stops reading the response partway through. 😳 That makes the client's TCP implementation advertise a zero window to the server.

For every large HTTP response, the server ends up holding the response data in its sending queue. How much data gets held depends on the size of the send buffer and the advertised window. If the clients never read the data in their receive queues, and therefore never clear the persist condition, the server keeps holding that data indefinitely. 🥶 Since there may be a limit to the operating system kernel memory available for TCP buffers, this can lead to DoS for legitimate connections by locking up the resources they need. And if this keeps going for an extended period, it starves TCP buffers and connection blocks, so legitimate existing connections and new connection attempts start failing. 💀

A clever application needs to detect attacks like this on connections that aren't making progress, and it could close those connections. ✨

Some applications, though, may have pushed all their data into the TCP socket and then closed the socket. That leaves the connections with no controlling process, and these are called orphaned connections. 👻 Orphaned connections might be left holding data in their sending queue forever.

The US Computer Emergency Readiness Team (CERT) has released an advisory about this [VU723308] and is making vendors aware of this DoS scenario. 🚨

7.2. Informative References 📚

Okay bestie, these are the "nice to read but not required" sources. Here's the full list, exactly as it appears:

[RFC2616]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
            Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
            Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
            Text on Security Considerations", BCP 72, RFC 3552,
            July 2003.

[RFC4732]   Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
            Denial-of-Service Considerations", RFC 4732,
            December 2006.

[TCPM]      IETF, "TCP Maintenance and Minor Extensions (tcpm) -
            Charter", <http://datatracker.ietf.org/wg/tcpm/charter/>.

[VU723308]  Manion, A. and D. Warren, "TCP may keep its offered
            receive window closed indefinitely (RFC 1122)",
            November 2009, <http://www.kb.cert.org/vuls/id/723308>.

Authors' Addresses 💌

Ok so here's where you can find the people who wrote this doc. Slide into their inboxes if you have questions, no cap 🫶

Murali Bashyam 🦋

Murali Bashyam
Ocarina Networks, Inc.
42 Airport Parkway
San Jose, CA  95110
USA

Phone: +1 (408) 512-2966
EMail: mbashyam@ocarinanetworks.com

Mahesh Jethanandani 🌸

Mahesh Jethanandani
Cisco
170 Tasman Drive
San Jose, CA  95134
USA

Phone: +1 (408) 527-8230
EMail: mjethanandani@gmail.com

Anantha Ramaiah 💜

Anantha Ramaiah
Cisco
170 Tasman Drive
San Jose, CA  95134
USA

Phone: +1 (408) 525-6486
EMail: ananth@cisco.com
📦 where this page comes from