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

Sam Hartman <hartmans-ietf@mit.edu> Thu, 19 September 2013 00:02 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 30E3A11E8167 for <karp@ietfa.amsl.com>; Wed, 18 Sep 2013 17:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 2b9ipjYP9-fs for <karp@ietfa.amsl.com>; Wed, 18 Sep 2013 17:02:45 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5597611E80D3 for <karp@ietf.org>; Wed, 18 Sep 2013 17:02:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6EFD6203B7; Wed, 18 Sep 2013 20:02:06 -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 G_CsSG1iWwGH; Wed, 18 Sep 2013 20:02:05 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (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; Wed, 18 Sep 2013 20:02:05 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6A9FF80634; Wed, 18 Sep 2013 20:02:37 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Acee Lindem <acee.lindem@ericsson.com>
References: <94A203EA12AECE4BA92D42DBFFE0AE470305670B@eusaamb101.ericsson.se>
Date: Wed, 18 Sep 2013 20:02:37 -0400
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470305670B@eusaamb101.ericsson.se> (Acee Lindem's message of "Tue, 17 Sep 2013 22:34:52 +0000")
Message-ID: <tsl7ged65lu.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"
Cc: Sam Hartman <hartmans-ietf@mit.edu>, "karp@ietf.org" <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: Thu, 19 Sep 2013 00:02:51 -0000

>>>>> "Acee" == Acee Lindem <acee.lindem@ericsson.com> writes:

    Acee> Hi Sam, I don't necessarily agree that this one use case
    Acee> should greatly complicate the proposed key table entry
    Acee> format. However, I'm willing to listen to your proposal on how
    Acee> to handle this.

I don't think it should change the format at all.

Some document needs to describe how to use key tables for securing LDP.
That document needs to describe what algorithms should be used.

My proposal is that document has joint algorithms that map both to a
TCP-AO algorithm and  an UDP protection algorithm.

so you have a table in the document with three columns:

1) key table algorithm
2) TCP-AO algorithm to use when this key table entry is used
3) UDP protection algorithm to used when this key table algorithm is
used.

The alternative is to register two key table protocols (LDP-TCP and
LDP-UDP) with separate algorithm lists and require the admin to enter
two rows.

I thnik encoding a constant table from the document describing how to
use key table for LDP into the implementation is relatively easy.
Probably easier or same level of effort as supporting LDP-TCP and
LDP-UDP as separate key table protocols.