Re: [tcpm] TCP-AO review comments.

Stefanos Harhalakis <> Sun, 10 August 2008 12:07 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 05BD83A6DBB; Sun, 10 Aug 2008 05:07:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3E233A68D7 for <>; Sun, 10 Aug 2008 05:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kWPePxG2T2Zn for <>; Sun, 10 Aug 2008 05:07:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AE9873A6B13 for <>; Sun, 10 Aug 2008 05:07:45 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id m7AC7jK8006537; Sun, 10 Aug 2008 15:07:45 +0300
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id m7AC7j35027974; Sun, 10 Aug 2008 15:07:45 +0300
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id m7AC7aJx032430; Sun, 10 Aug 2008 15:07:37 +0300
Authentication-Results:; spf=neutral
Authentication-Results:; sender-id=neutral
From: Stefanos Harhalakis <>
To: Joe Touch <>
Date: Sun, 10 Aug 2008 15:07:35 +0300
User-Agent: KMail/1.9.9
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <>
Cc:, "Anantha Ramaiah (ananth)" <>
Subject: Re: [tcpm] TCP-AO review comments.
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

On Sunday 10 August 2008, Joe Touch wrote:
> Stefanos Harhalakis wrote:
> | Also, is there any good in including a (1-byte - or smaller with some
> | unused
> | bits) version field in TCP-AO? This will help similar future
> | extensions/replacements and will also allow for easier authentication
> | option
> | handshaking by falling back to the highest commonly supported method.
> <indiv hat on>
> Options don't typically have version numbers; they're implicit in the
> option KIND itself. IMO, that's why TCP-AO is requesting a new KIND value.

Agreed, but since this is a 'group of options' that exclude each other, a kind 
of initial handshake is inevitable. As far as I see it, even with just 
TCP-MD5 and TCP-AO there is an initial handshake problem for deciding which 
one of them both ends support (no?). Practically this makes the transition 
from MD5 to AO a hard issue. Considering this, in the future (lets say in 5 
years) another such option 'upgrade' won't be feasible.

Of course a new KIND is required for TCP-AO but I believe that this should be 
the last one for the "series" of TCP authentication options. In fact, this 
may not be considered as a different 'KIND' of options, unless the SYN-senter 
negotiations all authentication options and the SYN-receiver selects the best 
that it supports. Since this isn't possible with limited TCP options space 
and SYN-cookies issues, something different is required (versioning).

Do you see another (better) long-term solution?
tcpm mailing list