Subject: Re: [karp] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" (<draft-ietf-karp-crypto-key-table-01.txt>) - Resending with Tim's Email Address Corrected

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Aug 2011 10:21:14 -0400

I'm a bit confused.
Virtual link packets are sent end-to-end, right? That is, I send the
packet directly to the router that is the other side of the virtual
link?

If so, why would I need separate keys for separate virtual links between
different endpoints?

---

From: Acee Lindem <[email-masked]>
Date: Mon, 1 Aug 2011 13:21:42 -0400

You are correct that it is the same pair of routers communicating. However, you can have multiple virtual links through different transit areas. Today, these can be the same or different keys/key chains. 
I guess one could argue that they do not need to differ. However, we allow different keys on different interfaces for unicast transmission over non-virtual links given the key existing key database keys (or should I call them indices to avoid confusion). 

Acee

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Aug 2011 13:36:27 -0400

>>>>> "Acee" == Acee Lindem <[email-masked]> writes:

    Acee> You are correct that it is the same pair of routers
    Acee> communicating. However, you can have multiple virtual links
    Acee> through different transit areas. Today, these can be the same
    Acee> or different keys/key chains.  I guess one could argue that
    Acee> they do not need to differ. However, we allow different keys
    Acee> on different interfaces for unicast transmission over
    Acee> non-virtual links given the key existing key database keys (or
    Acee> should I call them indices to avoid confusion).

OK.
so, we either need to accept these will be the same keys or we need to
include some rather protocol-specific details in the key table.

If you're using a per-peer keying strategy, then there's not a lot of
reason to use different keys.  If you're using a per-area keying
strategy and using the same key across an area then I'm not sure how we
should represent this in the crypto draft.

Russ/Tim, do you have any thoughts?