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