On 05/ 6/10 11:46 PM, Garrett D'Amore wrote:
On 05/ 6/10 08:32 AM, Nicolas Williams wrote:
On Thu, May 06, 2010 at 04:06:31PM +0800, Kacheong Poon wrote:
Suppose the process is able to exit but the socket lingers. In that
case will the lingering socket defeat resource controls?
I guess your concern is that somehow the peer goes away at the
*right* time and TCP stays in the FIN-WAIT-2 state for the
extended period of time. I further assume that you are using
this as an example of a new attack. And the goal is to create
as many lingering tcp_ts in the system as possible. For this
attack to be successful, there must be a peer co-operating. And
The peer need only accept connections though, right?
[...]
As I mentioned before, if folks are not comfortable with the
value ranges, I can change that. In this case, the max can be
changed to a similar value I mentioned previously for
TCP_ABORT_THRESHOLD, which is 2 hours. Does this help?
It's not the ABORT threshold that I'm worried about, but the TCP_LINGER2
timer. I recommend that the maximum for that be not more than some
smallish value such as 60s.
I agree. Wouldn't it also be possible to arrange for a "helpful" peer by
using a second cooperating process on the same system?
The peer needs to be a special program, such as a raw
socket program which sends/receives TCP packets directly.
In Solaris, only privileged apps can do that. But if
the app is privileged, it can do other more "interesting"
things directly than this.
I'm approaching the mind, given the earlier discussion, that we need to
have a project to examine this problem, and that it may be out of scope
for this project. Nevertheless, as we lack a mechanism for ARC to
express anything other than via opinion, perhaps derailing (and a
subsequent vote to approve) just to facilitate an opinion that suggests
that this problem be examined might be in order.
Which problem are you referring to here? AFAICT, there
is no new problem mentioned in this email thread.
--
K. Poon.
[email protected]
_______________________________________________
opensolaris-arc mailing list
[email protected]
