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

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

Return-Path: <jmh@joelhalpern.com>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0993F21F9CBD for <karp@ietfa.amsl.com>; Tue, 10 Sep 2013 02:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u0eP+6h7rSp for <karp@ietfa.amsl.com>; Tue, 10 Sep 2013 02:47:55 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5708621F8749 for <karp@ietf.org>; Tue, 10 Sep 2013 02:47:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 47B591C07EB; Tue, 10 Sep 2013 02:47:55 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9803A20112A; Tue, 10 Sep 2013 02:47:54 -0700 (PDT)
Message-ID: <522EEACC.6030707@joelhalpern.com>
Date: Tue, 10 Sep 2013 05:47:56 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
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 <hartmans-ietf@mit.edu>
References: <tsl61u9a9o1.fsf@mit.edu>
In-Reply-To: <tsl61u9a9o1.fsf@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: karp@ietf.org
Subject: Re: [karp] Handling of LDP hello packets and the crypto table
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=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.

Yours,
Joel

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
> karp@ietf.org
> https://www.ietf.org/mailman/listinfo/karp
>