Re: [tcpm] Is this a problem?

MURALI BASHYAM wrote:
> I agree with Caitlin and your previous responses; this is an
>  application
> problem.
> 
> So we are placing the responsibility for protecting system-wide TCP resources such as buffers
> and connections on all the TCP based applications out there? 

Yes - applications can always start extra TCP connections, and can
override default socket sizes, so those resources are already under
application control. They are managed by the OS as a whole, i.e., when
the OS runs out, the application gets that feedback, and reacts accordingly.

> Which "application"
> are you referring to here? BGP? NFS ? CIFS? HTTP? SMTP? FTP? The entire application
> community? Potentially several or all of these apps are vulnerable. How do we bring all these 
> protocols into a single agreeable framework and  accomplish the right thing? 

Any application can misbehave. Any application can hold off receiving
data it has asked for. If the sender side application cares, it cuts off
the connection. If it doesn't, it leaves the connection in place.

TCP doesn't read minds.

...
> Applications cannot discriminate between a connection that's stalled due to network
> congestion and a connection that's being stalled by a malicious receiver who has closed
> his receive window forever. And for how long the connection has been in in this stalled state etc.

Applications shouldn't discriminate between these. First, there's no
difference between a connection that's being stalled maliciously and one
that's being stalled legitimately. There's no requirement that TCP not
be stalled for a particular interval. You'd be disabling TCP's ability
(feature) to work over such environments arbitrarily if you change this.

> And what about multi-application servers? Surely each application here is running as an
> independent process and indvidually they don't have the system wide awareness that TCP has...

Nor should it. First, as I noted in other mail, TCP doesn't necessarily
have system-wide information - that's an *assumption*. You're talking
about the kernel making decisions, not TCP. TCP could be implemented in
user space, or in the kernel in a way that it is isolated from
information about other connections. That's another reason this isn't
TCP's job.

> 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.
> 
> Applications can implement a fixed or even an adaptive timeout, but unless they can make
> the above distinction i am pointing out, they will be knocking out legitimate (albeit slow) 
> connections, i.e there will be a fairness issue. 

And they'll still be knocking out legitimate (albeit slow) receivers
that have a good reason to send a zero window for some period of time -
like while you insert a new DVD to backup to.

> Applications do not have visibility into TCP connection
> sender's state to solve the fairness issue. 

Visibility into the state of a single connection does not solve this
issue. You simply know that the receiver is not accepting data at this
time - this is a feature of TCP. It's not a bug.

> A solution which penalizes legitimate connections is clearly a broken one.

Agreed!

> 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...).

> How do you propose to carry out these attacks without changing the client side TCP stack in the 
> windows or linux kernel? The vulnerability which we have demonstrated and addressed requires a simple user 
> level program which anyone with a little, basic programming background can write today. Clearly the bar to creating these attacks you are pointing out is higher.

It's not a vulnerability unless the application lets it be one. It's a
feature, and no, it shouldn't be disabled just because one
interpretation of what is happening is "DOS attack".

Is it a DOS attack to receive lots of connections at once? Is it a DOS
attack to recieve a connection that opens then doesn't send data for a
while? All of these are legitimate behaviors of TCP - as is having the
receiver stall the sender.

Joe

Re: [tcpm] Is this a problem?

Attachment: signature.asc