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

Joe Touch <touch@ISI.EDU> Wed, 29 July 2009 11:45 UTC

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F402B3A6A73; Wed, 29 Jul 2009 04:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5OTgxXscHKFK; Wed, 29 Jul 2009 04:45:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F0E3A3A62C1; Wed, 29 Jul 2009 04:45:09 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id n6TBit5h019014; Wed, 29 Jul 2009 04:44:57 -0700 (PDT)
Message-ID: <>
Date: Wed, 29 Jul 2009 04:44:54 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20090605)
MIME-Version: 1.0
To: Iljitsch van Beijnum <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:, " IESG" <>
Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication
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: <>, <>
X-List-Received-Date: Wed, 29 Jul 2009 11:45:11 -0000

Hash: SHA1

Iljitsch van Beijnum wrote:
> On 29 jul 2009, at 12:48, Lars Eggert 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.
> Second, it's not like TCP-MD5 isn't being used. As such, "historic"
> wouldn't apply. "Deprecated", maybe.
> Third, why is it exactly that we can't simply move from MD5 to IPsec to
> protect BGP sessions??

This is addressed in the TCP-AO document:

- ---

   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
   fact, we recommend the use of IPsec and IKE, especially where IKE's
   level of existing support for parameter negotiation, session key
   negotiation, or rekeying are desired. TCP-AO is intended for use only
   where the IPsec suite would not be feasible, e.g., as has been
   suggested is the case to support some routing protocols, or in cases
   where keys need to be tightly coordinated with individual transport
   sessions [Be07].

- ---

   This document differs from an IPsec/IKE solution in that TCP-AO as
   follows [RFC4301][RFC4306]:

   o  TCP-AO does not support dynamic parameter negotiation.

   o  TCP-AO uses TCP's socket pair (source address, destination
      address, source port, destination port) as a security parameter
      index, rather than using a separate field as an index (IPsec's

   o  TCP-AO forces a change of computed MACs when a connection
      restarts, even when reusing a TCP socket pair (IP addresses and
      port numbers) [Be07].

   o  TCP-AO does not support encryption.

   o  TCP-AO does not authenticate ICMP messages (some ICMP messages may
      be authenticated when using IPsec, depending on the

- ---

See also the Security Considerations section.
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -