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

"Anantha Ramaiah (ananth)" <> Sun, 24 February 2008 05:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E7353A6B9F; Sat, 23 Feb 2008 21:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ff4VGrihTF1l; Sat, 23 Feb 2008 21:48:26 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id E62113A69F9; Sat, 23 Feb 2008 21:48:26 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B93503A6850 for <>; Sat, 23 Feb 2008 21:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XbX-TZzP05ST for <>; Sat, 23 Feb 2008 21:48:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BEB2E3A6C68 for <>; Sat, 23 Feb 2008 21:48:14 -0800 (PST)
Received: from ([]) by with ESMTP; 23 Feb 2008 21:48:10 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m1O5mAxA004151; Sat, 23 Feb 2008 21:48:10 -0800
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id m1O5m6R4024135; Sun, 24 Feb 2008 05:48:08 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 21:48:04 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 23 Feb 2008 21:47:44 -0800
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] Handling of FIN in the reassembly queue
Thread-Index: Ach2gJBsYUd4u8yHR42vYfj0o1sPOwAFbgPA
References: <> <> <> <> <> <>
From: "Anantha Ramaiah (ananth)" <>
To: Andre Oppermann <>, David Borman <>
X-OriginalArrivalTime: 24 Feb 2008 05:48:04.0299 (UTC) FILETIME=[D2C861B0:01C876A8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3119; t=1203832090; x=1204696090; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20Handling=20of=20FIN=20in=20the =20reassembly=20queue |Sender:=20; bh=8D1dK8aRqUcS20M+IcFiDDbbm03RcOVgG68VvEUiH0E=; b=Doqo6oUuAKRok89OuQ4KoUb5qume/ll5J8hAU+MAtEdUanmwi6bTbnXZTj vWWl7MgvLWbOrgI1dodu9pu2G1DQwtDNGuro5NN2d6PDDj/IkN8Sa15ZpQhi OnRSNb8/LZkxq8QxPl1tHJxO34T88KC9qBX+60ZHpWek1haCQxds4=;
Authentication-Results: sj-dkim-1;; dkim=pass ( sig from verified; );
Subject: Re: [tcpm] Handling of FIN in the reassembly queue
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> 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

- 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,

tcpm mailing list