Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]

"Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy@nasa.gov> Thu, 02 October 2008 17:59 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955BE28C142; Thu, 2 Oct 2008 10:59:23 -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 BDFAC28C13E for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 10:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.366
X-Spam-Level:
X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9hQkmhQy4lLL for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 10:59:21 -0700 (PDT)
Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id D057028C116 for <tcpm@ietf.org>; Thu, 2 Oct 2008 10:59:20 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 57C3179A53; Thu, 2 Oct 2008 12:59:43 -0500 (CDT)
Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m92Hxg4T029052; Thu, 2 Oct 2008 12:59:42 -0500
Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Oct 2008 12:59:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 2 Oct 2008 12:59:42 -0500
Message-ID: <B5A5E01F9387F4409E67604C0257C71E5B8955@NDJSEVS25A.ndc.nasa.gov>
In-Reply-To: <48E502A1.5060006@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: Ackksywn5m1ZacUKTKOtAUnjb7ekQQAAl7yg
References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> <20081002001625.GQ60793@zod.isi.edu> <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> <48E502A1.5060006@isi.edu>
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy@nasa.gov>
To: "Joe Touch" <touch@ISI.EDU>, "Lars Eggert" <lars.eggert@nokia.com>
X-OriginalArrivalTime: 02 Oct 2008 17:59:42.0305 (UTC) FILETIME=[A5534510:01C924B8]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
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: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

>-----Original Message-----
>From: Joe Touch [mailto:touch@ISI.EDU] 
>Sent: Thursday, October 02, 2008 1:19 PM
>
>FWIW, we're dealing not only with what RFC2223 says in this regard, but
>the current IETF culture of when to use "updates".
>
>As I've noted, there are other extensions to TCP that are more 
>"updates"
>than this. We have a roadmap document to more clearly explain the
>relationship of components to 793; when that document is updated,
>tcpsecure should be added to that. Given the complexity of that
>document, this label isn't going to help, and IMO will misdirect
>implementers to include this where it wasn't necessary.
>
>I see no reason to lead the charge of changing IETF culture on this
>issue with this document, and specific reasons NOT to use this document
>as the defining case.


It's just my personal opinion, but I'm in full agreement with Joe.
Further, I think that if people are interpreting "updates" as "we
should read and consider implementing", then I'm especially hesitant
to have IPR-encumbered documents "update" 793, as it becomes an
advertisement attached to the base of TCP.

I also feel that tcpsecure is really a stop-gap to handle packets
with spoofed addresses, that could've/should've been caught
elsewhere (RFC 4953) and in more powerful ways (ingress filters,
ipsec, md5, gtsm, etc.) depending on deployment particulars.  It
happens to be a nice and effective stop-gap, but the long-term
solution is to make spoofed packets become nonexistent, at which
point we'll no longer need tcpsecure. 

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