Re: [tcpm] Some comments on tcpsecure

Fernando Gont <fernando@gont.com.ar> Sat, 05 April 2008 23:53 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529753A6A9C; Sat, 5 Apr 2008 16:53:48 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56ABE3A6A9C for <tcpm@core3.amsl.com>; Sat, 5 Apr 2008 16:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.055
X-Spam-Level:
X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, SARE_RECV_SPEEDY_AR=0.808]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSEJfzqAgVDf for <tcpm@core3.amsl.com>; Sat, 5 Apr 2008 16:53:46 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 37B5E3A6810 for <tcpm@ietf.org>; Sat, 5 Apr 2008 16:53:45 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A8BA25A899E; Sat, 5 Apr 2008 20:53:58 -0300 (ART)
Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m35NrdO1031661; Sat, 5 Apr 2008 20:53:40 -0300
Message-Id: <200804052353.m35NrdO1031661@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 05 Apr 2008 20:51:05 -0300
To: Joe Touch <touch@ISI.EDU>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <47F7E2D0.8010802@isi.edu>
References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 05 Apr 2008 20:53:57 -0300 (ART)
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Some comments on tcpsecure
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At 05:36 p.m. 05/04/2008, Joe Touch wrote:

>As I said before:
>
>         TCP *has* an MSL requirement (RFC793)
>                 this means that TCP segments should not live
>                 in the network beyond approx 2 minutes

Yes, and this requirement cannot be met, as it is based on the 
assumption that the IP TTL can be enforced. (Not to say that the MSL 
sort of imposes a requirement on the TTL you set in IP packets. If 
you set a TTL of say 240, then the TTL becomes 4 minutes, and 2*MSL 
becomes eight minutes.

As a result, if anything, this is as incorrect as requiring ICMPs to 
be in window. Well, unless you run TCP on anything other than IP....



>         ICMP does *not* have a requirement to respond with an MSL
>                 so a TCP segment's header can exist inside
>                 an ICMP packet long after the segment's MSL period
>
>As a result, it remains incorrect to validate a TCP segment inside 
>the ICMP as needing to be "in window".

If there's an error, the the window won't advance, and in the event 
the window does advance, then the error was not really "hard". And it 
would have been incorrect to abort the TCP connection. (see e.g., 
Clark's paper).



>>Your argument against (2) is that...mmm... that would be incorrect, 
>>because it would assume that every packet is an attack. But you do 
>>want to advocate ICMP filtering at firewalls.
>
>Correct. If an individual host or subnet wants to assume that ALL 
>ICMPs are suspect, then that's its decision - and that already 
>happens at some firewalls.

Welcome to the real world. We're suspicious by default.



>What "everyone implements" isn't the issue; that is covered in BCPs 
>when the IETF agrees with it and things like RFC 2525 (Known TCP 
>Implementation Problems) when the IETF does not feel it is 
>appropriate to change the standard merely to align with what is deployed.

What "everyone implements" isn't the issue? ahem... "rough consensus 
and running code".

There's no code that runs what you're describing, Joe. Everybody is 
doing what is described in the ICMP attacks draft.

Kind regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm