Subject: Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited

From: Stefanos Harhalakis <[email-masked]>
Date: Fri, 1 Aug 2008 13:06:40 +0300

I'm resending this as a reply to the 'new' thread just to change the spammy 
subject. Sorry for the duplicate.

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.

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?

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 1 Aug 2008 13:23:39 -0400

Stefanos Haralakis wrote:
> 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.
> 

By "application layer" I did not mean to limit the scope to
a user-space application running under a classic user/kernel
OS. Rather, I simply met the set of entities that uses the
TCP layer as a client.

Even when the TCP layer allocates resources itself, it is
doing so as an agent of a specific client/connection/listen.
Setting policy on what is a wise use of resources will  
always belong above the TCP layer, even if some implementations
delegate enforcement of that policy to the TCP layer.

Please keep in mind that any document coming through TCPM has
to make sense not only for the conventional user/kernel style
OS, but for embedded web servers that are part of devices or
TCP offload devices with the TCP layer implemented in silicon.
Treating everything above the TCP layer as an amorphous blob
is the only way to do this. Standardization within specific
sub-families of those amorphous blobs are best done in other
forums. We need to focus on telling them how TCP is supposed
to function, without telling them how to manage memory.

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Sun, 3 Aug 2008 22:07:53 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Mahesh Jethanandani
>Sent: Thursday, July 31, 2008 2:37 PM
>To: [email-masked]
>Subject: [tcpm] Persist condition clarification draft, now 
>"clarification of sending behavior" draft - comments solicited
>
>Apologies for sending this message twice, but did not realize that my 
>previous subject line attracted some spam filters (including my own).
>
>During the TCPM meeting in Dublin, Wes wanted to encourage readers on 
>this mailing list to read the short (2 pages if you remove the boiler 
>plate part) draft on "Clarification of Sender Behavior Under Persist 
>Condition" draft.
>
>To enable a quick read, I have cut and pasted the relevant sections 
>here. As noted in the meeting, this draft  tries to clarify the sender 
>behavior without getting into the details of the DoS scenario and the 
>possible solutions. Just to reiterate, it is this draft and not the 
>original persist draft that we are trying to table for 
>adoption as a WG 
>item.

Thanks for sending the text.  As just a TCPM participant: I've read
it, and I don't have any major problem with it, though there are
some editorial items I noticed.  I'm personally in-favor of sending
it through TCPM.  It seems very non-controversial to me in its
conclusion and the examination of existing code seemed to show that
it made sense to lay out in an RFC rather than just trusting that
implementers will understand 1122 and the potential for DoS if they
don't have some mechanism for reaping TCBs stalled in persist.

As TCPM co-chair, I hope other people will chime in for or against
taking this on as a WG item in the next couple weeks.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm