Re: [karp] Handling of LDP hello packets and the crypto table

"Joel M. Halpern" <> Tue, 10 September 2013 09:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0993F21F9CBD for <>; Tue, 10 Sep 2013 02:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2u0eP+6h7rSp for <>; Tue, 10 Sep 2013 02:47:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5708621F8749 for <>; Tue, 10 Sep 2013 02:47:55 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47B591C07EB; Tue, 10 Sep 2013 02:47:55 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9803A20112A; Tue, 10 Sep 2013 02:47:54 -0700 (PDT)
Message-ID: <>
Date: Tue, 10 Sep 2013 05:47:56 -0400
From: "Joel M. Halpern" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Sam Hartman <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [karp] Handling of LDP hello packets and the crypto table
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Sep 2013 09:48:00 -0000

This is an interesting question.
I can live with either answer.

Instinctively, I tend towards two separate entries.  This is because 
there is nothing obvious that ties the mechanisms used with the UDP 
Hellos to the mechanism used with TCP-AO.
On the other hand, it is presumably the case that implementing crypto 
algorithms is sufficient work that there is likely to be a relationship 
in practice.  And your point about reduced configuration by using the 
same keys is worth noting.

The one concern I have about using a single entry and a registry 
describing both sides is whether there will be many different 
combinations that folks have a reason (good, bad, or otherwise) to use. 
  As long as the number of combinations is small, this compound entry 
seems tractable.


On 9/9/13 6:54 PM, Sam Hartman wrote:
> Hi.
> This is the first of two questions about LDP hello packets.
> The second question will come after this is answered and has to do with
> automated key management.
> LDP requires both UDP-based hello packets and TCP-based sessions.
> The hello packets can be multicast or unicast.
> I'd like to focus for a moment on the unicast hello packets and the TCP
> sessions.
> How should these be handled in the key table?
> One possibility is that we assign two different protocols one for LDP
> session and LDP hello.
> That would allow us to keep the algorithms distinct: use any TCP-AO
> algorithm for the TCP sessions and do something for UDP.
> There's a huge downsidhe: operational complexity.
> It would be easy to configure  LDP so that one of the two exchanges is
> authenticated but the other is not.
> Also, it seems strongly undesirable for manual key management to
> require two keys.  If we do a good job of choosing algorithms and KDFs
> there is no security requirement to have separate keys in the crypto
> table for  LDP hello and LDP sessions.
> However, I think a much better approach would be to have a single row
> for an LDP unicast peer.  We'd somehow need to configure both TCP-AO and
> the LDP hello security from the same parameters.
> One approach would be to reuse the TCP-AO MAC algorithm for LDP hello
> packets.
> Another approach would be to have LDP ciphersuites including a TCP-AO
> algorithm and an appropriate paired UDP authentication  algorithm.
> Thoughts?
> _______________________________________________
> karp mailing list