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

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Sep 2013 18:54:06 -0400

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?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Sep 2013 05:47:56 -0400

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:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Sep 2013 11:02:03 -0400

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

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

Agreed.

I tend to give configuration and operation complexity very heavy weight
because I want our solutions to be easy enough to deploy that they are
actually deployed.
So, I strongly prefer the single entry approach if the number of
combinations is small.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 17 Sep 2013 22:34:52 +0000

Hi Sam, 

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

Thanks,
Acee

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Sep 2013 20:02:37 -0400

>>>>> "Acee" == Acee Lindem <[email-masked]> 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.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 30 Sep 2013 17:10:42 +0000

This would be fine with me. Note that since LDP discovery (UDP) can be
1-to-many and LDP sessions are 1-1 (TCP), the deployment model may require
different key-table interface selectors anyway. However, the change you
propose would allow a deployment model where one key is used for both.
Thanks,
Acee