Re: [tcpm] Some comments on tcpsecure

Fernando Gont <fernando@gont.com.ar> Fri, 04 April 2008 20:12 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 0FFA43A6CF2; Fri, 4 Apr 2008 13:12:57 -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 368973A6C65 for <tcpm@core3.amsl.com>; Fri, 4 Apr 2008 13:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[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 M1c0sbAdEe5O for <tcpm@core3.amsl.com>; Fri, 4 Apr 2008 13:12:55 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 042F03A6CEB for <tcpm@ietf.org>; Fri, 4 Apr 2008 13:12:53 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 840FF5A7460; Fri, 4 Apr 2008 17:13:02 -0300 (ART)
Received: from notebook.gont.com.ar (168-226-14-25.speedy.com.ar [168.226.14.25] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m34KCk8U022643; Fri, 4 Apr 2008 17:12:47 -0300
Message-Id: <200804042012.m34KCk8U022643@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 04 Apr 2008 17:10:54 -0300
To: Joe Touch <touch@ISI.EDU>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <47F68794.6050100@isi.edu>
References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@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]); Fri, 04 Apr 2008 17:12:59 -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 04:55 p.m. 04/04/2008, Joe Touch wrote:

>>The first one is the ICMP attacks draft 
>>(draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the 
>>security implications of ICMP on TCP conenctions, it does not 
>>reference the I-D. IIRC, this had already been pointed out by Joe 
>>(?). As far as the specifications are concerned, you shouldn't 
>>bother to fix TCP-based reset attacks if you don't fix the the ICMP-based ones.
>
>Agreed; should this doc recommend filtering out ICMPs as a result? 
>(there's no in-window checks that are meaningful, since ICMPs are 
>not guaranteed to be timely) I.e., something stronger than "there's 
>nothing we can do", which is what is implied in the current security 
>considerations.

Ha... So we have been arguing about the ICMP stuff for almost four 
years on the idea that it is too aggressive to require ICMP error 
messages to be in-window, and now we're going to propose to filter 
them out? Seems ironic to me. (And you cannot do it with "frag needed 
and DF bit set". Well, you *could* implement the new PMTUD that does 
not rely on ICMP error messages. But ignoring ICMP error messages 
will increse the PMTUD convergence time).

And, for what is worth, strictly speaking there's no such a thing as 
a TCP MSL, either. TCP's MSL is based on the assumption that the IP 
TTL is decremented at least once every second. And this is not 
warranted, either. There's not such enforcement as there is in, e.g., Delta-t.



>>The other doc is the port randomization draft 
>>(draft-tsvwg-port-randomization).
>
>Also ISN randomization (RFC-1948), for similar reasons. Even though 
>some of the RST attacks span the entire window, knowing the ISN can 
>help during the initial handshake and shortly thereafter.

Agreed. (Although the math in "Slipping in the window" does not 
assume the attacker can predict the ISN).

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