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

["Anantha Ramaiah (ananth)" <[e-mail]>]

Hi David,

Firstly, I appreciate your explanations on TCP design and the
differences between standard and implementation, those are all good. 

That said, it appears that this is what is being said (at least that is
what is being inferred in the email exchanges) :-

Case 1:
Abort by the application and OS
==================================

 "The application OR any entity (like OS) which is instructed by the
application to abort the TCP connection when deemed necessary". "The OS
can abort the TCP connection when deemed necessary". These actions seems
to enjoy full compliance of RFC 793/1122. 

Also an example : if there are 270 connections hanging out in persist
state for 110 days, the system administrator chooses to clear some of
these connections, now system administrator is acting on behalf of the
system and may not be the application, this is not a violation of the
RFC, it appears.

WHEREAS

Case 2:
Aborts done inside TCP layer
============================

Assuming that one implementation chooses to have a design like :
instructs each individual components in the system like transports layer
to abort some connections and thereby relinquish system resources when
deemed necessary using an explicit or implicit feedback from the OS. Now
this action seems to be violating the RFC since it was done inside the
jurisdiction of TCP code. I am having hard time understanding this. To
me, it is pure implementation thingy.

To me all the above actions (case 1 and 2), either are all compliant to
RFC OR all of them aren't. May be it is just me.

Please read on...

Lets take the example of one mitigation for "SYN attacks" (I think also
mentioned in the recent SYN flood informational RFC)

It talks about detecting "possibly" malicious connections hanging out
there in half-ESTAB state and the possible mitigations. One of the
simple mitigations is to toss the "oldest" embryos and make room for the
"new ones" and all of these actions doesn't violate any RFC. 

It could be argued for SYN flood case : Why should one do that, they can
let the connections hang out forever, timeout happens OR the host
crashes etc., the point is that you want to make an "attempt" to permit
new, possibly legitimate connections, conserve system resources for
legitimate clients. Is this foolproof?, no, there are corner cases
everywhere in every solution. That doesn't mean you shouldn't be having
anti-DOS solutions in place.

Now the above draft talks about connections which are going to be
established and NOT already established. But I can see a lot of
similarities in the goals between the SYN flood and persist drafts. 

Now, I know people may say that the persist draft is totally different
since you are talking about connection that are in >= ESTAB state. The
state of affairs so far seems to be : you can't simply touch the TCP
connection persisting since RFC 1122 tells you to keep this forever, but
wait, you can kill them, but please do so only in the context of the
application and may be OS, but not inside TCP since doing so violates
RFC. But remember, it could be that someone chose to enhance the their
TCP stack's anti-DOS capabilities with some algorithm they believed
would help, terming that as a RFC violation seems too far fetched.

Anyways, I am stuck on the way RFC compliance is measured here and I am
thinking we are applying too much layering here than mandated by the
generic nature of the existing RFC.

$0.02,
-Anantha

> -----Original Message-----
> From: David Borman [mailto:[e-mail]] 
> Sent: Thursday, November 29, 2007 9:09 AM
> To: MURALI BASHYAM
> Cc: TCP Maintenance and Minor Extensions WG; Mark Allman; Joe Touch
> Subject: Re: Summary of responses so far and proposal moving 
> forward[WasRe:[tcpm] Is this a problem?]
> 
> 
> On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote:
> ...
> > The second aspect is the ability of the application to explicitly 
> > cause the TCP connection to leave the ZWP state at the 
> specified time 
> > independent of available resources. There are applications where 
> > having this level of control over the TCP connection makes 
> sense (web, 
> > game servers).
> > But aborting this connection with trigger from TCP or OS or 
> > application is a protocol violation, i don't buy the fact 
> that if the 
> > OS does it, it's not a violation, that's what i was referring to as 
> > pure wordplay.
> 
> Fine.  Call it wordplay.  There's nothing wrong with that, because you
> *have* to get the words right.  You have to be crisp on the 
> protocol definition.  The implementation can blur the 
> boundaries, but the  
> protocol definition can't.   The aborting of a connection 
> (whether in  
> persist or any other state) when the other side is alive and 
> responding has to be done by the application.  TCP should not 
> be doing that without direct instructions from the 
> application.  Whether that is done directly by the 
> application by using the existing abort or user timeout 
> interface, or whether a new interface is defined to allow the 
> application tells the OS to run a timer and abort the 
> connection when the timer goes off, it is still being done 
> under the direction of the application.
> 
> 
> > A protocol is a contract between the sender and receiver 
> here, and the 
> > contract defines the wire behaviour.
> 
> The TCP protocol is what is defined in RFC 793/1122, and any 
> other RFCs that are applicable.  It is more than just the 
> wire behavior.
> 
> 
> > I care about the wire behaviour of the connection, and if i observe 
> > the behaviour of the connection in the ZWP state prior to 
> this change, 
> > i see ACKs and probes exchanged infinitely. With this change (no 
> > matter who does it, OS, app, TCP), i see ACKs and probes being 
> > exchanged for some time, followed by a RST segment to abort the 
> > connection.
> >
> > Do you agree that if we do the latter without changing the 
> wording of 
> > RFC1122, it's a protocol violation?
> > My claim all along has been that it is.
> 
> There already exists two mechanisms for the application to 
> abort a connection, directly with the abort interface, or 
> indirectly with the user timeout on the send interface, and 
> you will get the same wire behavior, a connection in persist 
> state gets aborted.
> 
> The only protocol problem here is to have TCP abort a 
> connection in ZWP state without the application having first 
> explicitly asked for that to happen.  And if you need a new 
> interface to provide that functionality, then that will be a 
> change to the TCP protocol.
> 
> The OS freeing up resources when they run out by doing things 
> like aborting connections is not a protocol violation, 
> because it isn't TCP making that decision.  Take that to the 
> extreme, and you'd be arguing that the system crashing is a 
> TCP protocol violation, and that's just silly.
> 
> >
> >
> > If we agree that it's a violation, then it's a standards 
> track nature 
> > of draft.
> 
> If it changes TCP, in this case adding a new User/TCP 
> interface, then it should be on the standards track.
> 
> 			-David Borman
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm
> 


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