[tcpm] draft-mahesh-persist-timeout-01

Wanted to bring to this mailing list some of the discussion we have had off the list regarding the following draft.

 http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-01.txt
  "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 7-Mar-07, <draft-mahesh-persist-timeout-01.txt> 

Erik Nordmark wrote:

> As we discussed in Prague, using a fixed timeout for zero-window is 
> too simplistic.
> I don't know how much detail it makes sense to go into in the draft on 
> more elaborate schemes.
Kacheong Poon wrote:
> I am not too sure if the proposed scheme is effective for
> more clever attacks.  For example, an attacker can always
> make sure that the receive window is not completely close.
> So TCP will never enter persist state.  But the effect of
> the attack is still the same.  And an attacker may just want
> the victim to be in such a memory shortage state temporarily
> for some reason.  The use of a timer (even as modified as the
> above) is not that useful.  I suspect that there are other
> schemes which can "work around" the method as suggested.
>
> It seems to me that an OS should provide some form of
> protection in a more general context for this kind of outside
> attack.  But I guess it probably does not belong to IETF as
> it is more an OS security/resource control topic, and does not
> need to be "interoperable."
Kacheong Poon wrote:
> I'm curious what the gaming server will do in this case.  The
> write to the connection will block.  Will it just close the
> connection after write is blocked for a long time?  I know that
> TCP will still keep the connection around after the close.  I'm
> just wondering if a "force abort after close" timer is also
> useful.  It is more or less a super-set of the FIN-WAIT-2 timer.
> And the difference between this and your scheme is that the timer
> starts even if TCP is not in persist state.  This may be easier
> to comprehend by a sys admin or app programmer as it does not
> involve any TCP protocol knowledge.  Just a thought.
Mahesh Jethanandani wrote:
>> I'm curious what the gaming server will do in this case.  The
>> write to the connection will block.  Will it just close the
>> connection after write is blocked for a long time?  I know that
>> TCP will still keep the connection around after the close.  I'm
>> just wondering if a "force abort after close" timer is also
>> useful.  It is more or less a super-set of the FIN-WAIT-2 timer.
>> And the difference between this and your scheme is that the timer
>> starts even if TCP is not in persist state.  This may be easier
>> to comprehend by a sys admin or app programmer as it does not
>> involve any TCP protocol knowledge.  Just a thought.
>>
>>   
> The assumption is that the gaming server had no more data to send. In 
> this particular case it did. Because the client had not closed the 
> connection, the gaming server had to continue to send updates to the 
> client. When the write returned a block, application did not know if 
> the write is blocked because of issues in the network or because the 
> client was reliably sending a zero window. I think it is important to 
> distinguish between the two cases as the latter has the tone of a DoS 
> attack. The draft specifically addresses the latter case.
>
> It is also not clear what "long time" is. What might be a long time in 
> application terms might be a death knell for TCP when it is dealing 
> with hundred of these kind of connections. That is why we talk about a 
> LRU scheme in TCP itself to knock out connections that are in persist 
> state and are not moving data.

Anantha Ramaiah wrote:
> I'm curious what the gaming server will do in this case.  The 
> > write to the connection will block.  Will it just close the 
> > connection after write is blocked for a long time?  I know 
>   
>
> Well, it depends on the application. 
>
>   
>> > that TCP will still keep the connection around after the 
>> > close.  I'm just wondering if a "force abort after close" 
>>     
>
> Even if closes the connection, it moves FINWAIT1, but would never get an
> ACK since according to RFC
>  
> "If the RCV.WND is zero, no segments will be acceptable, but
>  special allowance should be made to accept valid ACKs, URGs and
>  RSTs."
>
> Since most likely, the segment len would be > 0. [Since there may still
> be data in the retransmit queue]
>
>   
>> > timer is also 
>>     
> useful.  It is more or less a super-set of the 
>   
>> > FIN-WAIT-2 timer.
>> > And the difference between this and your scheme is that the 
>> > timer starts even if TCP is not in persist state.  This may 
>> > be easier to comprehend by a sys admin or app programmer as 
>> > it does not involve any TCP protocol knowledge.  Just a thought.
>>     
>
> Assuming you get to FINWAIT2. The point here is, the situation described
> in the draft is a "special case" which when hit adversly affects the
> robustness of the protocol, since it is a potential DOS scenario. 
>
> One other thing is that the draft is targetted to be an informational
> one and also this attempts to document the incorrectness found in the
> RFC 1122's verbiage. (This response comes from your other observation
> about whether this really belongs to standards or simply an OS issue) 
>
>   
>> > 
>> > 
>> > 
>>     
>>> > > We have implemented it for NetBSD. The changes are fai
Kacheong Poon wrote:
> that TCP will still keep the connection around after the 
> >> close.  I'm just wondering if a "force abort after close" 
>   
> > 
> > Even if closes the connection, it moves FINWAIT1, but would never get an
> > ACK since according to RFC
> >  
> > "If the RCV.WND is zero, no segments will be acceptable, but
> >  special allowance should be made to accept valid ACKs, URGs and
> >  RSTs."
> > 
> > Since most likely, the segment len would be > 0. [Since there may still
> > be data in the retransmit queue]
>   
>
>
> Suppose the other side is advertising a zero window.  I think
> after the close of a socket, TCP will not send out a FIN to the
> other side as there is still unsent data.  This means that TCP
> will not move to FIN-WAIT-1 state.  Could you elaborate on what
> you referred to above?
>
> The idea of a "force abort after close" is regardless of
> what state a TCP connection is in, the timer will abort,
> meaning sending a RST, the connection.  For example, a clever
> attacker can make sure that the receive window is not really 0
> such that the connection is not in persist state, but is still
> alive.  One way is to acknowledge one byte in, say every 60 seconds.
> This is effectively the same kind of attack described in your
> draft.  If we have a "force abort after close" timer, it means
> that TCP will abort the connection even in the above case.  Note
> that the timeout value should be chosen carefully.
>
>
>
>
>   
>> > Assuming you get to FINWAIT2. The point here is, the situation described
>> > in the draft is a "special case" which when hit adversly affects the
>> > robustness of the protocol, since it is a potential DOS scenario. 
>>     
>
>
> If the state is FIN-WAIT-2, it means that there is no
> un-acknowledged data and TCP does not have anything in the
> send buffer.  I suppose there is no problem.  And I think
> most, if not all, TCP implementations have a FIN-WAIT-2 timer
> to kill the hanging PCB.  It is generally not a problem.
>
>
>   
>> > One other thing is that the draft is targetted to be an informational
>> > one and also this attempts to document the incorrectness found in the
>> > RFC 1122's verbiage. (This response comes from your other observation
>> > about whether this really belongs to standards or simply an OS issue) 
>>     
>
>
> The question I referred to is a more general resource control
> mechanism in an OS.  It does not seem to me that a TCP timer
> is very effective in protecting many different kinds of attacks,
> one of which is described in your draft.  I am not saying that
> we should not do anything in this particular problem.  But
> I guess we probably need a more general mechanism for the wider
> scoped issue.
>   
Anantha Ramaiah wrote:
> Anantha Ramaiah (ananth) wrote:
> > 
>   
>>> > >> that TCP will still keep the connection around after the 
>>>       
> > close.  I'm 
>   
>>> > >> just wondering if a "force abort after close"
>>>       
>> > > 
>> > > Even if closes the connection, it moves FINWAIT1, but would 
>>     
> > never get 
>   
>> > > an ACK since according to RFC
>> > >  
>> > > "If the RCV.WND is zero, no segments will be acceptable, 
>>     
> > but  special 
>   
>> > > allowance should be made to accept valid ACKs, URGs and  RSTs."
>> > > 
>> > > Since most likely, the segment len would be > 0. [Since there may 
>> > > still be data in the retransmit queue]
>>     
> > 
> > 
> > Suppose the other side is advertising a zero window.  I think 
> > after the close of a socket, TCP will not send out a FIN to 
> > the other side as there is still unsent data.  This means 
> > that TCP will not move to FIN-WAIT-1 state.  Could you 
> > elaborate on what you referred to above?
>   
>
> Yes, that is correct and I stand corrected. TCP wouldn't move to
> FINWAIT1 at all. Looks like I mis-understood your original text, so if I
> understand correcty you are suggesting an timeout for each state of the
> TCB? Typically we don't have TIMEOUT's on FINWAIT1 state. In any case to
> get back to focus on the current draft, it all arises since RFC 1122
> indefinetely recommends persist state.
>
>   
>> > 
>> > The idea of a "force abort after close" is regardless of what 
>> > state a TCP connection is in, the timer will abort, meaning 
>> > sending a RST, the connection.  For example, a clever 
>> > attacker can make sure that the receive window is not really 
>> > 0 such that the connection is not in persist state, but is 
>> > still alive.  One way is to acknowledge one byte in, say 
>> > every 60 seconds.
>>     
>
> Well, assuming that the application does timeout, so applications would
> have the responsibility to timeout.
>   

[tcpm] draft-mahesh-persist-timeout-01

Attachment: mahesh.vcf