Re: [tcpm] Some comments on tcpsecure

Joe Touch <touch@ISI.EDU> Sun, 06 April 2008 20:05 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 F2B693A6DEE; Sun, 6 Apr 2008 13:05:59 -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 1479F3A6DEE for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 13:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 kvpoPa4FkiMo for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 13:05:58 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1F6553A6DC1 for <tcpm@ietf.org>; Sun, 6 Apr 2008 13:05:58 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m36K5hs5026804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Apr 2008 13:05:45 -0700 (PDT)
Message-ID: <47F92D13.4020809@isi.edu>
Date: Sun, 06 Apr 2008 13:05:39 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
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>
In-Reply-To: <200804061042.m36AgYGx028003@venus.xmundo.net>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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: multipart/mixed; boundary="===============1817309857=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Let's try to move this forward constructively...

Let's assume that we all want to make TCP's processing of error messages 
depend on the coarse connection state - i.e., different interpretation 
of errors in pre-established vs. established states.

	This is basically how the current TCP ICMP processing
	is already defined, and would extend it to be more uniform,
	which seems reasonable.

Let's further assume, that in the established state, that "making 
progress" should invalidate receipt of error messages to the contrary.

	This is a *departure* from current TCP ICMP processing, which
	basically says that errors trump progress. Whether this
	is reasonable depends on how slowly you want TCP to
	make progress while receiving legitimate errors
	(e.g., due to flakey links, multipath/routing errors, etc.),
	vs. making TCP robust to such behavior.

	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

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.

If you want to recommend that we change ICMP interpretation when making 
progress, then base your decision on a direct metric of making progress, 
not an incorectly inferred one.

Joe


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