On 05/ 6/10 03:29 AM, Garrett D'Amore wrote:
My point was that these timers could affect the resources that are
consumed on the system *after* a socket is closed. Ultimately, that
means that any limits already in existence that limit open files won't
necessarily apply to these timers.
While these timers don't necessarily *create* a *new* weakness, my
concern is that increasing the value of the timers may make it *easier*
for a malicious program to create a DoS situation.
I think the options neither make it easier nor harder. One can
do the same type of resource exhaustion attack right now. And
the concern is really about a generic resource control (*) in the
network stack, which is outside the scope of this case.
As I mentioned in a previous mail, if folks are not comfortable
with the value ranges, I can certainly change that. For example,
TCP_ABORT_THRESHOLD (tcp_ip_abort_interval) can be limited to
2 hours (oops, this means that inter-planetary TCP communication
won't work in Solaris anymore...)
Its not new.. its a situation where the DoS I described above can be
*easier*. I'm not sure just how *much* easier it is, but that's the
nature of the question I'm asking.
"Difficulty" is certainly subjective. Does having 2 fewer
lines of code mean "easier"? How about 20 lines? I think the
question should be practical or impractical (assuming it is
always possible). IMHO, the new options do not introduce new
attack in practice, nor make an impractical attack practical.
(*) Note that the early abort timeout when the system is
short in memory is not affected by these options.
--
K. Poon.
ka-cheong.p...@oracle.com
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
