[tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited

[Mahesh Jethanandani <[e-mail]>]

Apologies for sending this message twice, but did not realize that my 
previous subject line attracted some spam filters (including my own).

During the TCPM meeting in Dublin, Wes wanted to encourage readers on 
this mailing list to read the short (2 pages if you remove the boiler 
plate part) draft on "Clarification of Sender Behavior Under Persist 
Condition" draft.

To enable a quick read, I have cut and pasted the relevant sections 
here. As noted in the meeting, this draft  tries to clarify the sender 
behavior without getting into the details of the DoS scenario and the 
possible solutions. Just to reiterate, it is this draft and not the 
original persist draft that we are trying to table for adoption as a WG 
item.

1.  Introduction

  RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY
  keep it's 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.  The RFC goes on to say that it is important to remember that
  ACK (acknowledgment) segments that contain no data are not reliably
  transmitted by TCP.  Therefore zero window probing SHOULD be
  supported to prevent a connection from hanging forever if ACK
  segments that re-opens the window is lost.  The condition where the
  sender goes into the ZWP mode is typically known as the persist
  condition.  The problem is applicable to TCP and TCP derived
  transport protocols like SCTP.

  A consequence of adhering to the above requirement mandated by RFC
  1122 is that multiple TCP receivers (clients) advertising a zero
  window to a busy server indefinitely (by reliably acknowledging the
  ZWP), could exhaust the connection and buffer resources of the sender
  (server).  In such cases, to achieve robustness, the system should be
  able to take appropriate action on those TCP connections and reclaim
  resources.  The purpose of this document is to clarify that such
  actions are in the spirit of RFC 1122 and they don't violate RFC
  1122.  The remainder of the document briefly describes the DoS
  scenario, analyzes the current verbiage surrounding the ZWP in RFC
  1122 and attempts to disambiguate the notion presented by RFC 1122.

2.  Discussion

  Having the sender accumulate buffers and connection table entries
  when the receiver has deliberately and maliciously closed the window
  ultimately leads to resource exhaustion on the sender.  This
  particular dependence on the receiver to open its zero window can be
  easily exploited by a malicious receiver TCP application to launch a
  DoS attack against the sender.  In this scenario the sender's
  legitimate connections do not get established and already established
  well behaved TCP connections are unable to transmit any data.  The
  sender enters the persist condition and is stuck waiting indefinitely
  for the receiver to open up its window.

  To illustrate this, consider the case where the client application
  opens a TCP connection with a HTTP [RFC2616] server, sends a GET
  request for a large page and stops reading the response.  This would
  cause the client TCP to advertise a zero window to the server.  For
  every large HTTP response, the server is left holding on to all the
  response data in it's send queue.  If the client never clears the
  persist condition, the server will continue to hold that data
  indefinitely.  Multiple such TCP connections stuck in the same
  scenario on the server would cause resource depletion resulting in a
  DoS situation on the server.

  In such scenarios it should be possible for the application or the
  system or a resource management entity to instruct TCP to terminate
  connections stalled in the persist condition.  These actions are
  necessary to prevent resource exhaustion on the server.

  An extensive discussion took place recently about this issue on the
  TCPM WG mailing list [TCPM].  The general opinion seemed to be that
  terminating a TCP connection in persist condition does not violate
  RFC 1122.  In particular the operating system, a resource manager, or
  an application can instruct TCP to abort a connection in the persist
  condition.  TCP itself SHOULD not take any action and continue to
  keep the connection open as mandated by RFC 1122 unless otherwise
  instructed to do so.  The exact mechanism by which the instruction to
  abort the connection is conveyed to TCP is an implementation decision
  and falls beyond the scope of the current memo.  To determine which
  TCP connection to abort the entity can use the connection attributes
  obtained from some interface similar to STATUS call mentioned in RFC
  793.








-- mahesh

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm