Re: [tcpm] poll for adopting draft-gont-tcp-security

Joe Touch <touch@ISI.EDU> Sat, 04 July 2009 16:20 UTC

Return-Path: <touch@ISI.EDU>
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 3DC763A69B7 for <tcpm@core3.amsl.com>; Sat, 4 Jul 2009 09:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 EhZ+ZZyPBFXO for <tcpm@core3.amsl.com>; Sat, 4 Jul 2009 09:20:04 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 17C953A68D5 for <tcpm@ietf.org>; Sat, 4 Jul 2009 09:20:04 -0700 (PDT)
Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n64GK6Xm005223; Sat, 4 Jul 2009 09:20:08 -0700 (PDT)
Message-ID: <4A4F8136.2040004@isi.edu>
Date: Sat, 04 Jul 2009 09:20:06 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov> <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <D04557F4-BEAF-4885-AF33-D9643AF5D049@surrey.ac.uk> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar>
In-Reply-To: <4A4EDFEB.4030008@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>, Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sat, 04 Jul 2009 16:20:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
...
> <sidetrack>
...
> Has anybody
> argued against ignoring ICMP source quenches meant for TCP connections?

Source quenches were supposed to be deprecated a while back, but never
made it into a doc.

> The "in-window" check is useful as a
> mitigation technique for the PMTU counter-measure -- however, the one
> described in the I-D is mainly based on the idea of "check for progress
> on the connection", which I believe parallels the idea in PLPMTUD. --
> and I don't recall people arguing against that idea, either.

Ignoring certain ICMPs when the connection is continuing to make
progress might be reasonable.

However, this has *nothing* to do with checking the in-window of the
ICMP payload, which is inappropriate. As I and others have pointed out
many times, routers are not required to send ICMPs in a timely basis, so
there's no reason that an out-of-window ICMP should be treated any
differently from an in-window one.

> Also, see the reviewers in the Acks of the I-D.. that's people from most
> of the major TCP implementations. And the ideas in the I-D are the
> running code we have and we use. However, we are so full of ourselves
> that we tell implementers that the code they have implemented, which has
> been running the Internet for the last 20 years or so, is "buggy",

OK, this is the sort of argument that holds no water. Convince us that
something is useful and correct. Pleaase cease claiming that
implementations define standards.

...
> Want to now what the industry did in response? -- The have ignored our
> consensus.

We need to continue to pull in the direction of standards, regardless of
what implementers do. If you care that much about the implementations,
then change them. It'd be more productive than simply documenting what
has been implemented instead.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpPgTYACgkQE5f5cImnZrtItACff2IahTUi4HniiXXfSGZo14Ld
qgYAoJip2LIYpYvLUwF3ZfTODNlF+e79
=5o96
-----END PGP SIGNATURE-----