Re: [tcpm] status of TCP-MD5 after TCP-AO publication

Lars Eggert <lars.eggert@nokia.com> Wed, 29 July 2009 11:14 UTC

Return-Path: <lars.eggert@nokia.com>
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 7DE5C3A6953; Wed, 29 Jul 2009 04:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 eqJRltiTJwRb; Wed, 29 Jul 2009 04:14:10 -0700 (PDT)
Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 7A4843A68C9; Wed, 29 Jul 2009 04:14:10 -0700 (PDT)
Received: from [IPv6:2001:df8::80:225:ff:fe45:eccf] ([IPv6:2001:df8:0:80:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n6TBE2wP005816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 14:14:03 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Message-Id: <54734E7B-7003-423E-86F3-97C03E2971E3@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <FB33B8FD-308B-4867-902E-131382969C35@muada.com>
Content-Type: multipart/signed; boundary="Apple-Mail-22--24102701"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 29 Jul 2009 13:13:56 +0200
References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> <FB33B8FD-308B-4867-902E-131382969C35@muada.com>
X-Mailer: Apple Mail (2.935.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 29 Jul 2009 14:14:03 +0300 (EEST)
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "iesg@ietf.org IESG" <iesg@ietf.org>
Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication
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: Wed, 29 Jul 2009 11:14:11 -0000

Hi,

On 2009-7-29, at 13:02, Iljitsch van Beijnum wrote:
>> at the meeting, the question came up which status TCP-MD5 should
>> have after TCP-AO is published. Specifically, whether it should be
>> obsoleted by TCP-AO and/or if it should be reclassified as Historic.
>
> First of all, I'd like to see some operational experience with TCP-AO.
> Don't throw away your old shoes until you know whether the new ones  
> fit.

so are you saying we should *neither* obsolete TCP-MD5 *nor* move it  
to Historic?

> Second, it's not like TCP-MD5 isn't being used. As such, "historic"
> wouldn't apply. "Deprecated", maybe.

There is no way to express this for an RFC. There are two options: "A  
obsoletes B", which is indicated in the document header, and "A is  
reclassified as Historic" in the RFC Editor database.

> Third, why is it exactly that we can't simply move from MD5 to IPsec
> to protect BGP sessions??

I refer you to the extensive discussion that happened when draft- 
bonica was first presented to the WG, which I have no interest in  
rehashing.

Lars