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
- [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)