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

"Eddy, Wesley M. (GRC-RCN0)[VZ]" <> Thu, 02 October 2008 17:59 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 955BE28C142; Thu, 2 Oct 2008 10:59:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDFAC28C13E for <>; Thu, 2 Oct 2008 10:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.366
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9hQkmhQy4lLL for <>; Thu, 2 Oct 2008 10:59:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D057028C116 for <>; Thu, 2 Oct 2008 10:59:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 57C3179A53; Thu, 2 Oct 2008 12:59:43 -0500 (CDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id m92Hxg4T029052; Thu, 2 Oct 2008 12:59:42 -0500
Received: from ([]) by 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, 02 Oct 2008 12:59:42 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: Ackksywn5m1ZacUKTKOtAUnjb7ekQQAAl7yg
References: <> <> <> <> <>
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>
To: Joe Touch <touch@ISI.EDU>, Lars Eggert <>
X-OriginalArrivalTime: 02 Oct 2008 17:59:42.0305 (UTC) FILETIME=[A5534510:01C924B8]
Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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