Subject: Re: [tcpm] Please read

From: Stefanos Harhalakis <[email-masked]>
Date: Fri, 1 Aug 2008 12:47:26 +0300

On Thursday 31 July 2008, Caitlin Bestler wrote:
> Is an RFC really needed?
>
> I've always assumed that the application layer MAY
> do pretty much whatever it wants. Further application
> layer servers SHOULD protect their own resources against
> abusive clients. Those protection mechanisms MAY include
> terminating connections.
>
> All of that is true independent of any specific method
> of abusing server resources.

Since this is an OS issue that will affect all running applications and it is 
impossible to ensure that all TCP-listening applications won't be 
exploitable, I believe it is best to take some (customizable) measures at the 
OS side too (if understand correctly, that's what the resource management 
entity, even if it is implemented as a user-space part). Of course any 
application is able to enforce stricter rules.

Apart from that, I believe that the problem is not well defined. I don't 
exactly understand what differentiates a zero sized window with a one-byte 
window, etc... Transferring a 1MB file with 1-byte window is essentially the 
same (no?). It is also almost the same as never acking the last data segment 
and sending dup-acks for the previous for some time, or just acking 1 byte 
every N retransmits, etc... Where exactly do you draw the line?

Taking a broader look, since TCP's fundamental assumption is that the remote 
end is trustworthy, perhaps it is better to look at this and other TCP attack 
methods as a resource allocation problem and handle it as such. Most of the 
time there won't be such an issue but in cases of an attack, there can be 
algorithms that "evenly" allocate the shared resource (like available sockets 
or available buffer space). Also, to my knowledge there are cases where it is 
impossible to distinguish between legitimate behavior and malicious behavior. 
Most probably, taking at look at the shared resource approach will solve this 
and perhaps other future problems too that can be caused by attacks or 
legitimate remote-ends. At the end, we may only need to point to that problem 
and indicate what a good policy is made of.

Nonce?

p.s. I'll be away from keyboard for the next two weeks (starting tomorrow) so 
please excuse any delayed replies.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Matt Mathis <[email-masked]>
Date: Thu, 31 Jul 2008 18:17:55 -0400 (EDT)

Doesn't this create a huge opportunity for a DoS attack, since an attacker can 
send requests with forged from addresses, and the server has to burn cycles 
and/or commit memory, when it is never going to see the next packet?

I believe that this problem is fundamental to anything that is piggybacked on 
the SYN and has killed every attempt at using the handshake to eliminate later 
transactions.  The server wants to know for sure that the client is alive and 
responding before committing more than incidental resources (e.g. SYN queue, 
constructing a SYN-cookie, etc) to the connection.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

On Thu, 31 Jul 2008, Mahesh Jethanandani wrote:

> 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

---

From: "Murali Bashyam" <[email-masked]>
Date: Fri, 1 Aug 2008 12:58:14 -0700

> application is able to enforce stricter rules.

The resource management entity can be part of TCP or it can be in the
OS/application and do its work based on feedback from TCP.

> every N retransmits, etc... Where exactly do you draw the line?

There are solutions for those scenarios, UTO based. UTO doesn't kick in when
the peer is
offering zero window. The attempt in this draft is to  *enable* alternatives
to the TCP sender side by
clarifying the 1122 verbiage and allowing resource management approaches,
UTO based approaches to handle this condition
etc.

> and indicate what a good policy is made of.

That's the attempt here, to highlight the implications of this condition and
possible solutions (to be posted in the second draft and in the
combined draft earlier). The solutions are general enough to extend to the
other scenarios you are describing.

-- 
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 04 Aug 2008 06:25:57 -0700

Changing the Subject to align it with the other thread.

> abusive clients. Those protection mechanisms MAY include
That is true, and if you read 793 is states it as such. What causes some 
of confusion is the verbiage in 1122. While 1122 is not contradicting 
what is stated in 793, if you look at most implementations, the verbiage 
in 1122 is implemented to the letter T but hardly anyone has implemented 
anything mentioned in 793 for the same scenario. The result is a DoS attack.

Take Linux as an example. Here are some sample comments from the code 
base and note the confusion
> 241 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L241>         *//* *WARNING* RFC 1122 forbids this/*
> 242 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L242> */         */*
> 243 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L243> */         * It doesn't AFAIK, because we kill the retransmit timer -AK/*
> 244 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L244> */         */*
> 245 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L245> */         * FIXME: We ought not to do it, Solaris 2.5 actually has fixing/*
> 246 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L246> */         * this behaviour in Solaris down as a bug fix. [AC]/*
> 247 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L247> */         */*
> 248 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L248> */         * Let me to explain. icsk_probes_out is zeroed by incoming ACKs/*
> 249 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L249> */         * even if they advertise zero window. Hence, connection is killed only/*
> 250 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L250> */         * if we received no ACKs for normal connection timeout. It is not killed/*
> 251 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L251> */         * only because window stays zero for some time, window may be zero/*
> 252 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L252> */         * until armageddon and even later. We are in full accordance/*
> 253 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L253> */         * with RFCs, only probe timer combines both retransmission timeout/*
> 254 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L254> */         * and probe timeout in one bottle.                             --ANK/*
> 255 <http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_timer.c#L255> */         *//*
>   
The actual implementation of Linux has TCP keeping track of connections 
in persist condition and terminating them when the number of "orphaned 
connections" exceeds a certain threshold.

We believe that is because of the confusion around the verbiage of 1122. 
And thus the clarification needed.

-- mahesh