Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]

[MURALI BASHYAM <[e-mail]>]

----- Original Message ----
> From: Joe Touch <[e-mail]>
> To: MURALI BASHYAM <[e-mail]>
> Cc: David Borman <[e-mail]>; Anantha Ramaiah <[e-mail]>; TCP Maintenance and Minor Extensions WG <[e-mail]>
> Sent: Sunday, December 2, 2007 10:32:52 AM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
> 
> 
> 
> MURALI BASHYAM wrote:
> ...
> >> Applications should have changed long ago. Some definitely need to
> >> catch up. There is no way to handle DOS attacks with legacy
> >> applications written in a legacy manner.
> > 
> > I think you missed my point, let me explain. Application here
> does
> 
 NOT care
> > about reliable delivery of data to the peer after it has closed
> the
> 
 connection.
> > Hence SO_LINGER is out. Web behaves this way and by any standards
> it
> 
 is not a legacy
> > application.  
> 
> By your metrics, so are any modifications of the TCP API that require
> rewriting the app. Web servers have been multithreaded for a long
> time
> 
 -
> and even reuse threads to avoid thread creation (see Apache).
> 
> > Can you explain why an application should keep a connection or
> socket
> 
 state around 
> > after it has closed the connection AND it does not care
> about
> 
 reliable delivery of data to the peer?
> 
> If it doesn't care about reliable delivery, why did it use TCP? Why
> didn't it ABORT the connection instead of CLOSE?

Reliable delivery is important to the application, but for it to introduce blocking semantics
on close and hold up connection resources when 99% of the time data is delivered reliably, 
is not an acceptable trade-off. For high speed web servers, this is an important requirement.

> 
> Your example is inconsistent; if you care about reliable delivery AND
> you care about resource attacks you stick around. If you don't, you are
> susceptible to DOS attacks.
> 
> > If it did, they would be using SO_LINGER already, hence my
> comment
> 
 about not making
> > socket layer usage recommendations to the app. Even in this
> scenario,
> 
 it's important
> > that *****TCP**** does not run out of connection and
> buffer
> 
 resources, however.
> 
> TCP doesn't have resources. The OS does.

TCP borrows resources from the OS, just like any other entity in the system does. 
TCP is the one that knows how to proportion resources among its connections,
elephants vs mice, well-behaved vs malicious receivers etc.
How do you expect the OS to handle this? And handle it properly?

> 
> > I think the key point this issue illustrates is that it is
> TCP's
> 
 resources which are under attack
> > here, and not the application's. I think this distinction has
> emerged
> 
 in this email thread 
> > a while back, and i don't think there is any disagreement abt it.
> 
> There have been a few of us who believe that the resources under attack
> are the OS's, not TCP, and then there are the authors - who believe
> otherwise.

Not necessarily, by that token, so is SYN flood attack on connection memory, and it is
the OS that's responsible for memory management, isn';t it?. Isn't that an OS issue?

Every protocol attack and vulnerability can be regarded as an OS issue, to keep the protocol designer's
life simple :-), that's a poor argument. Another TCP attack is out of order reassembly vulnerability, holding large
number of buffers in the out of order queue waiting for the in order segments to arrive.
Sure, from an OS perspective there are  a large number of buffers being held up in the
TCP's queues, does that make it a OS issue? It's protocol vulnerabilities and loopholes
 that's being exploited here. Protocol designers have a responsibility to think about resource lifetimes
during protocol design, TCP is no exception to it. That's just good protocol design 101.

> 
> > In most modern systems, these are managed as distinct resources
> and
> 
 TCP resources (read
> > connection memory and buffer memory) can get starved with
> app
> 
 resources available in plenty.
> > If application resources are under attack, that's
> application
> 
 responsibility, of course.
> 
> An app IS under attack when its connections are attacked.

I agree, the app is under attack too, but the question is who has the visibility to manage this
better and under ALL circumstances without impacting performance under normal conditions. To manage this vulnerability caused by a requirement in the TCP protocol, it's not a good idea to ask the application to enable SO_LINGER, when the app has made 
a conscious decision not do so in the interest of performance.  

Can you think of WHY this shouldn't be done in TCP, with the go-ahead from the application via a socket
option and/or globally by the adminstrator? I've asked this question quite a few times, and i've not received a satisfactory answer from the list so far, i've heard responses 
  a) that it is too risky for TCP to do this,
  b) that it's a flawed application that's causing this, 
  c) that the OS has failed its responsibility to manage resources, 

None of these are convincing, when we all agree that it's a protocol vulnerability being exploited by the attacker. Let's just fix the protocol.

Murali


> 
> Joe
> 
> 




      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ


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