Re: [tcpm] Please read

On Fri, Aug 1, 2008 at 2:47 AM, Stefanos Harhalakis <v13@v13.gr> wrote:

> On Thursday 31 July 2008, Caitlin Bestler wrote:
> > Is an RFC really needed?
> >
> > I've always assumed that the application layer MAY
> > do pretty much whatever it wants. Further application
> > layer servers SHOULD protect their own resources against
> > abusive clients. Those protection mechanisms MAY include
> > terminating connections.
> >
> > All of that is true independent of any specific method
> > of abusing server resources.
>
> Since this is an OS issue that will affect all running applications and it
> is
> impossible to ensure that all TCP-listening applications won't be
> exploitable, I believe it is best to take some (customizable) measures at
> the
> OS side too (if understand correctly, that's what the resource management
> entity, even if it is implemented as a user-space part). Of course any
> application is able to enforce stricter rules.

The resource management entity can be part of TCP or it can be in the
OS/application and do its work based on feedback from TCP.

>
> Apart from that, I believe that the problem is not well defined. I don't
> exactly understand what differentiates a zero sized window with a one-byte
> window, etc... Transferring a 1MB file with 1-byte window is essentially
> the
> same (no?). It is also almost the same as never acking the last data
> segment
> and sending dup-acks for the previous for some time, or just acking 1 byte
> every N retransmits, etc... Where exactly do you draw the line?

There are solutions for those scenarios, UTO based. UTO doesn't kick in when
the peer is
offering zero window. The attempt in this draft is to  *enable* alternatives
to the TCP sender side by
clarifying the 1122 verbiage and allowing resource management approaches,
UTO based approaches to handle this condition
etc.

>
>
> Taking a broader look, since TCP's fundamental assumption is that the
> remote
> end is trustworthy, perhaps it is better to look at this and other TCP
> attack
> methods as a resource allocation problem and handle it as such. Most of the
> time there won't be such an issue but in cases of an attack, there can be
> algorithms that "evenly" allocate the shared resource (like available
> sockets
> or available buffer space). Also, to my knowledge there are cases where it
> is
> impossible to distinguish between legitimate behavior and malicious
> behavior.
> Most probably, taking at look at the shared resource approach will solve
> this
> and perhaps other future problems too that can be caused by attacks or
> legitimate remote-ends. At the end, we may only need to point to that
> problem
> and indicate what a good policy is made of.

That's the attempt here, to highlight the implications of this condition and
possible solutions (to be posted in the second draft and in the
combined draft earlier). The solutions are general enough to extend to the
other scenarios you are describing.

>
> Nonce?
>
> p.s. I'll be away from keyboard for the next two weeks (starting tomorrow)
> so
> please excuse any delayed replies.
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

-- 
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************
------------------------------ CONFIDENTIAL --------------------