Subject: Re: [karp] Comments on framework document: keystore

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 27 Jul 2010 08:27:20 -0700

On Wed, May 19, 2010 at 12:36 PM, Sam Hartman <[email-masked]> wrote:

>
>
> There is a comment after the description of the components in the
> framework document that perhaps the keystore is not needed.
>
> I think that at this stage in the work, the keystore clouds rather than
> adds clarity.  It seems to mix operator-provisioned and KMP-provisioned
> keys and explicitly mixes multiple types of keys (peer keys and traffic
> keys).
>
> I think that in terms of trying to understand the framework we should
> remove the key store.
>
> We may bring it back either as a better defined global concept when we
> get to a point where performance optimizations are well-understood, or
> more likely as a concept within a specific KMP.
>
> If the keystore is going to remain it needs to have a much more clearly
> defined role.
>

GML> Sam, Thanks for the thoughts. At this point, at least the way these
comments are expressed, I'm not sure I see a technical argument being stated
for why the key store is NOT needed. Your message seemed to express more of
a gut feel than a technical reasoning.

The current goal that the framework achieves is that the routing protocol
deamon does not need to know the details about how a key and the security
associations around it get created and configured. It needs only read it in
and use it. This gives us the benefit of being able, in the future, to move
from manually configured PSK's + SA parameters to KMP-created keys +
parameter without having to make significant changes to all the underlying
routing protocols.

Maybe that point did not come across clearly in the framework document? If
so, we need to make that more clear, either in the ASCII art or in the
textual explanation, so it is more quickly grasped by readers.

Thoughts?

As always, the discussion is appreciated. And thanks again for the
thoughtful review,
Gregory

>
> --Sam
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks