Re: [tcpm] Comments on TCP-AO Draft

"LANGE Andrew" <> Tue, 18 November 2008 21:34 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 629FB3A6B19; Tue, 18 Nov 2008 13:34:15 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B25CF3A6B19 for <>; Tue, 18 Nov 2008 13:34:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y5tzyultzj6Z for <>; Tue, 18 Nov 2008 13:34:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4DFAB3A6885 for <>; Tue, 18 Nov 2008 13:34:13 -0800 (PST)
Received: from ( []) by (ALCANET) with ESMTP id mAILYBRg012904; Tue, 18 Nov 2008 15:34:12 -0600
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Nov 2008 15:34:11 -0600
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Nov 2008 15:34:11 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 18 Nov 2008 15:34:10 -0600
Message-ID: <>
Thread-Topic: [tcpm] Comments on TCP-AO Draft
Thread-Index: AclI5XgHf+wZoobzTouVULb4S/pTOQACBnxQADVd9To=
References: <> <>
From: LANGE Andrew <>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>,
X-OriginalArrivalTime: 18 Nov 2008 21:34:11.0324 (UTC) FILETIME=[6545FBC0:01C949C5]
X-Scanned-By: MIMEDefang 2.64 on
Subject: Re: [tcpm] Comments on TCP-AO Draft
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: multipart/mixed; boundary="===============1397201686=="

Hi Wesley,

We can certainly discuss the issue.  Although there seems to be a typo below. Shouldn't the include option say that it is GOOD to include the data?

I've also includes some elaboration of the arguments inline.  Perhaps an explanation of where this requirement is coming from would help. 

<< elided >>

>1.4.1: " IETF-72 topic" sections "No current consensus was 
>reached on this topic, so no change was made."  This is a real 
>problem -- the logic is deeply flawed.  Allow me to restate: 
>One author of this document has appointed themselves the 
>arbiter of consensus.  This author disagrees with other 
>people, and therefore no "consensus" can ever be reached, so 
>the default case this author has chosen is to keep things they 
>way they like it.
> ...
>"..omit an explicit algorithm ID..." -- I've said this before, 
>this is a BAD IDEA^tm. The protocol utility of doing this is 
>minimal (1-bit increase in search space), and the operational 
>complexity goes up.  Not to mention, it makes it operationally 
>incompatible with existing implementations.

There was logic given to support each side of the argument.  My
understanding of the summary for each position is:

(position 1 - "include") Including information like algorithm ID
and k-bit is BAD because it aids in debugging of implementations
and of configurations.

Elaboration: Including this information allows debugging, and significantly aids in drilling down to the real problem.  I have had a direct hand in operating, engineering or architecting five major ISP networks, before working for a vendor.  Since then, I've been involved in a number of others.  The simple truth is that any additional information is very helpful, especially at 4am, when you've rebooted a peering router, and cannot explain why some of the peering sessions are up, and others aren't.  Misconfigurations take many forms, and being able to look, and see immediately that, during the reboot the local system failed back to a saved config with "ignore TCP options" or "use HMAC-SHA-1-96", and the other side is sending "use AES-128-CMAC-96" clears up the need for a phone call.  Also, in reality, it is rarely a simple as a phone call.  Tickets are created, phone calls are made, escalations happen, all the while traffic is misrouted, or not flowing at all.  The longer the outage, the bigger the bottom line impact. Having this information around reduces the impact, and shortens or eliminates the phone call.  Having been there at 4am, troubleshooting these sorts of things in the past, I know this.  And it hold true across operators. 

(position 2 - "don't include") Including this information is BAD
because it can expose information about the security parameters.
It doesn't aid in debugging of configuration because operators still
have to call each other in order to read off and verify keys.

Elaboration: Originally I was also of this position.   However, I came around when I considered the operational impacts.  We need to make this protocol as operator-friendly as possible.  That is why it is being created to begin with.  We shouldn't lose sight of deployability and maintainability in the quest to shorten an option by a byte (especially when we gain 3 from MD5 to start with.)  Also, we have had many strong security experts, such as ekr and Brian Weis (gentlemen, correct me if I'm misquoting you) say that putting algorithm ID in the packet does very little to make it harder for a bad guy to attack the session.  To be specific, the attacker has to be a man-in-the-middle to see the ALG ID to start with (whereas blind attacks are probably more likely).  In addition, the search space would be extended by a single bit.  We're already using very strong algorithms, and have the agility to add more.  Search is already infeasible with known state, and if that changes the right approach, and the secure approach is to introduce another algorithm. 

There seemed to be more people around position 2 than position 1,
but we should flag this and ask during the meeting, as well as
open this up on the mailing list to see what people prefer.  We
need to pick one and move on.

Elaboration: I haven't taken a poll, but we do need to keep in mind, that operators tend to be poorly represented, and they are the people who are going to be using this.

As an individual, and not a co-chair, I'm in the position 2 "don't
include" camp.

tcpm mailing list