Re: [tcpm] Is this a problem?

[Mahesh Jethanandani <[e-mail]>]

Joe Touch wrote:
> Applications know when a connection hasn't closed. They also know when a
> write would block due to insufficient socket resources. Either or both
> of these provide sufficient visibility to avoid the problem entirely.
>   
Knowing those two facts only gives applications some of the information. 
It still would not know why the write is blocked? You agree that 
penalizing legitimate connections is a broken implementation. How does 
application then differentiate between a legitimate connection that is 
slow and one that is malicious (by advertising a zero window for an 
extended period of time)?

It is important to understand that a slow legitimate connection is a 
behavior that is almost entirely contained within TCP but the client 
sending zero window can be a case of a malicious user level program 
(read externally triggered attack) not reading data. Looking into the 
TCP connection state allows us to differentiate between the two 
different conditions and treat the connections fairly.
> As you note, applications can solve this easily. Since it's their
> obligation to do so, and it's easy for them to do so, there's no reason
> to complicate the transport layer with this responsibility.
>   
The reality is that few applications if any implement any mechanism to 
detect a connection that is stalled in such a manner. Our experiment 
shows that  the most commonly used application (HTTP) used on some of 
the biggest web sites are vulnerable today holding on to connections in 
EST state for days. Yes, they should implement a mechanism, but can TCP 
count on it. What is it supposed to do if applications do not clear 
connections in a timely manner.

> Furthermore, does the propose solution solve the DOS problem? Aren't
> there other ways to keep a source stalled? (i.e., what about continued
> SACKs? or repeated ACKs indicating a lost segment? at the very least, we
> could ACK a byte at a time, sending 3-4 duplicate ACKs for each byte,
> which would keep the sender from opening its window and stall things a
> lot...).
>   
You are talking about a malicious TCP implementation that would require 
special permissions in a DDoS scenario. What we used was a simple user 
level program that required no special privileges to run.


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