Re: [tcpm] Handling of FIN in the reassembly queue

Andre,

> 
> After reading and sleeping one night over this excellent 
> discussion I realized that we are unsafe at any speed here.
> 
> We may get hit with a FIN attack just as we may get hit with 
> a RST attack.
> A FIN anywhere in the window is valid and gets queued in the 
> reassembly queue for later processing.  This wrecks a TCP 
> session by either ending it prematurely in one direction 
> (accepting the FIN closest to left edge), or by preventing 
> its legitimate ending (accepting only the first FIN and 
> waiting for data that never comes).  This is a serious 
> threat.  Maybe even more so than a pure RST attack with the 
> same complexity.  It is much more subtle and can cause long 
> hangs for TCP based protocols that do not have their own 
> keepalive ping exchange.  tcpsecure doesn't even mention it.
> I guess nodoby thought of the reassembly and its effects yet. 
>  FIN deserves its own section as well.

Actually as part of the data mitigation tcp-secure does mention FIN
attack, in the sense the strict ACK sequence number checking would
strengthen robustness in dealing with malicious data segments and that
includes FIN segments. 

FWIW, Murali and I are in the process of writing a document which
outlines the re-assembly (re-sequencing to use the correct terminology)
queue related DOS scenarios. We didn't consider FIN attacks as such..

> 
> The solution I've come up with is to only accept a FIN when 
> it matches the left edge (rcv_nxt) either perfectly or 
> accompanied by data that advances rcv_nxt (the missing 
> segment).  All data beyond that point in the reassembly queue 
> is then to be flushed.  All FINs that do not fulfill this 
> condition are to be ignored and not queued.  The only 
> remaining question then is whether to ignore the whole 
> segment data that came with the FIN.  Probably not.  We can't 
> say if this is real FIN or not and consequently we can't say 
> whether the segment data is real or not.  We however have to 
> assume it is real because we don't have any evidence to the 
> contrary (provided all tcp input validity checks have been 
> done previously).  This is a quite simple solution and it 
> avoids a lot of complexity in FIN handling in the reassembly queue.
> If my reasoning and rationale is agreed with I can write up a 
> FIN section for tcpsecure over the next few days.

I would think having a separate document to address this instead of
putting stuff in tcp-secure since :

- the one which you are talking is about formulating the rules about
what to do with out-of-order FIN. It makes sense for a descriptive
document (like your original email) and outline pros and cons of each
method.

- tcpsecure has a section on data mitigation but it is about correcting
the liberal ACK checking allowed by 793 and it applies to ANY data
segment and also FIN. 

- tcpsecure has come a long way, and adding more stuff at this point
sounds uneasy to me. But that's just me.. 

My few cents,

-Anantha
_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm