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

Sam Hartman <hartmans-ietf@mit.edu> Mon, 09 September 2013 22:54 UTC

Return-Path: <hartmans@mit.edu>
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 628CB21E80F1 for <karp@ietfa.amsl.com>; Mon, 9 Sep 2013 15:54:22 -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=[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 iVyclgzi+1ap for <karp@ietfa.amsl.com>; Mon, 9 Sep 2013 15:54:13 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDC711E8164 for <karp@ietf.org>; Mon, 9 Sep 2013 15:54:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5E1432021D for <karp@ietf.org>; Mon, 9 Sep 2013 18:53:54 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbTY0q0SdKS9 for <karp@ietf.org>; Mon, 9 Sep 2013 18:53:54 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (mb80536d0.tmodns.net [208.54.5.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for <karp@ietf.org>; Mon, 9 Sep 2013 18:53:53 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 761C689DD4; Mon, 9 Sep 2013 18:54:06 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: karp@ietf.org
Date: Mon, 09 Sep 2013 18:54:06 -0400
Message-ID: <tsl61u9a9o1.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [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: Mon, 09 Sep 2013 22:54:22 -0000

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?