Re: [tcpm] tcpsecure: how strong to recommend?

Mark Allman <mallman@icir.org> Sun, 30 September 2007 01:01 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbnBX-0001Ut-H2; Sat, 29 Sep 2007 21:01:27 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbnBX-0001Uj-39 for tcpm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 21:01:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbnBW-0001Ua-Pm for tcpm@ietf.org; Sat, 29 Sep 2007 21:01:26 -0400
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbnBR-00046R-Et for tcpm@ietf.org; Sat, 29 Sep 2007 21:01:26 -0400
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8U11DBS000688; Sat, 29 Sep 2007 18:01:13 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id A604A100A6EB; Sat, 29 Sep 2007 21:01:07 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A112B2AAE37; Sat, 29 Sep 2007 20:59:55 -0400 (EDT)
To: "Mitesh Dalal (mdalal)" <mdalal@cisco.com>
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
In-Reply-To: <13D1EAB852BE194C94773A947138483D04245252@xmb-sjc-21c.amer.cisco.com>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Car Phone
MIME-Version: 1.0
Date: Sat, 29 Sep 2007 20:59:55 -0400
Message-Id: <20070930005955.A112B2AAE37@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.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://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1597472055=="
Errors-To: tcpm-bounces@ietf.org

Hat off ... personal opinion ...

> i.e. are we labeling this changes as updates to rfc793 ?  Will we
> clearly state (if the document proceeds to standards track) to state
> "Updates: 793" in the title of the document ?
> 
> OR
> 
> are we looking it as an additional protocol that can be added/embedded
> to TCP (although there is no handshake to signal this understanding
> between the TCP peers to distinctly picture this as an option, but a
> small protocol nevertheless) and does not necessarily update the base
> spec ?

I cannot understand how this can be viewed as 'an additional protocol'.
That seems nonsensical to me.  To my way of thinking the mitigations in
the tcpsecure document **change** the previously specified response to
certain packets and therefore tcpsecure is necessarily an **update**.
Maybe its just me ...

allman



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