Re: [tcpm] Some comments on tcpsecure
Fernando Gont <fernando@gont.com.ar> Sun, 06 April 2008 22:41 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 538733A6B0A; Sun, 6 Apr 2008 15:41:24 -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 8C87D3A6B0A for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 15:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.162
X-Spam-Level:
X-Spam-Status: No, score=-0.162 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 THn6dpcQQ1sU for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 15:41:22 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 667CC3A69F2 for <tcpm@ietf.org>; Sun, 6 Apr 2008 15:41:21 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3C59A5A745A; Sun, 6 Apr 2008 19:41:36 -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 m36MfGKx010325; Sun, 6 Apr 2008 19:41:22 -0300
Message-Id: <200804062241.m36MfGKx010325@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 06 Apr 2008 19:38:34 -0300
To: Joe Touch <touch@ISI.EDU>
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <47F92D13.4020809@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> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@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]); Sun, 06 Apr 2008 19:41:35 -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:05 p.m. 06/04/2008, Joe Touch wrote: (Meta comment: The current version of the ICMP attacks draft is meant for the Informational path. I believe I have removed/rephrased those senteces which seemed to "propose" the mitigation-techniques, rather than simply document them. If I did a good job in this last revision, the doc shouldn't be far from being ready to be shipped to the IESG. The soft errors draft is already there. These two drafts, together with another one some of us will be submitting anytime soon would be of great help as a basis for further work that would include what you sketch bellow.) Please see my comments inline.... >Let's try to move this forward constructively... Agreed. [....] > I do believe we need to make this work in the case of > non-malicious behavior. Only then should we consider > whether or not it affords obfuscation protection against > attackers. > > Given this case, then *progress* is the metric. That implies: > - cache received ICMPs and log window state > - determine if the window moves after the ICMP > is received; if so, drop that ICMP (Thinking out loud, with no coffee in the last few hours ;-) ): I'd also add "Discard the ICMP message if there's no data in flight to the destination when the ICMP error message is received" (i.e., in such a scenario, there's no "forward progress" to be made). >One key issue above: it is NOT dependent on the window data in the >ICMP payload, for two reasons: > > 1) (my point) ICMPs are not required to be issued in a timely > fashion, or for every individual error, a legitimate situation > could involve receiving an old ICMP about an endpoint failure, > without receiving further updates on any particular schedule > > 2) (Fernando's point) ICMPs are currently implemented widely > as not being issued in a timely fashion, with the same results > as #1 > >I.e., it doesn't matter if you design for spec or common >implementations; either way, ICMP payload window information is not >relevant to the "making progress" issue. Agreed. You may say "making progress" and "requiring the TCP SEQ in the ICMP payload to be 'in-window'" are two different issues. The TCP SEQ check would help a bit in those scenarios in which an attacker might be able to spoof an ICMP error message, and cause the connection to be stuck for a little while (e.g., by means of causing congestion). That is, it would require more packets on the side of the attacker. However, if TCP waits for USER_TIMEOUT to check whether the connection is making forward progress, then this is basically the "hard errors should be considered to indicate soft errors when received for connections in any of the synchronized states" behavior, and thus an attacker could not exploit the so-called ICMP hard errors to perform reset attacks. (i.e., the "hard errors should be considered to indicate soft errors when received for connections in any of the synchronized states" becomes a degenerate case of the "checking for progress on the TCP connection" when TCP waits for USER_TIMEOUT seconds before concluding whether the connection is making progress or not). (FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as during what I called 'Initial Path-MTU Discovery', you probably don't want to wait, so that you get a good convergence time for the PMTUD). Kind regards, and thanks for the clarification above! -- 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
- [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- [tcpm] ICMP error origination timeliness Pekka Savola
- Re: [tcpm] ICMP error origination timeliness Joe Touch
- Re: [tcpm] ICMP error origination timeliness Anantha Ramaiah (ananth)
- Re: [tcpm] ICMP error origination timeliness Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)