Subject: [karp] Threats-reqs Issue 10 (was "Re: I-D Action: draft-ietf-karp-threats-reqs-05.txt")

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 1 Jun 2012 01:09:32 -0700

So we are agreed on all but two of your comments. One is on Req 21, and
I've asked Manav to reply to that. The other is issue 10. See inline...

On Thu, May 31, 2012 at 11:33 AM, Uma Chunduri <[email-masked]>wrote:

> **
> Hi Gregory,
>
> Changes look fine to me. See my comments in-line..[Uma]
> --
> Uma C.
>
>
>  ------------------------------
> *From:* Gregory Lebovitz [mailto:[email-masked]]
> *Sent:* Thursday, May 31, 2012 7:58 AM
> *To:* Uma Chunduri; Bhatia, Manav (Manav)
> *Cc:* [email-masked]; Brian Weis
>
> *Subject:* Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt
>
> Hello, Uma. Thanks for your input.
>
>
> On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri <[email-masked]>wrote:
>
>> **
>> Dear Authors,
>>
>> I read this version and the document is in good shape.
>>
>> If, it's not too late, I have few comments on the 05 version.
>>
>>
>> 1.a) Page 4: Section 1.  Introduction
>>     Third Bullet:
>>     "   o  Create specifications for cryptographic validation of routing
>>       message content."
>>     "The third bullet is being addressed in the SIDR
>>    working group."
>>    Though we can understand what SIDR is doing -  "routing message
>> content" just doesn't imply BGP message?
>>    I can understand what you are trying to say, but IMO, what is said is
>> not representative.
>>
>>
>
> How about this:
> NEW: The third bullet is being addressed in other efforts within the IETF.
> *For example, BGP message content validity is being addressed in the SIDR
> working group. *
> **
>

--SNIP--

>
>> 3. Section 1.1, Page 6:
>>    "If session or traffic
>>       keys are being used, KMP is responsible for generating them and
>>       determining when they should be renewed."
>>
>>    This is not necessarily the only way as it sounds. KMP can also be
>> used for only master key generation and
>>    traffic keys are generated from the same by the master key consumer.
>> And also determining when the keys should
>>    be renewed may not be KMP function. So I am not quite you define KMP
>> this way.
>>
>
> Understood. How about this:
>
> NEW:   In some routing protocols traffic keys are derived by the routing
> protocol from session / master keys. In this case, KMP is responsible for
> the session / master key generation. In other cases, there are only traffic
> keys (and no session / master keys), and KMP is responsible for the traffic
> key generation.
> *tracker ID 10.
>

>  *[Uma]: Perhaps you can drop "session/" in the above, as that sounds
> more synonymous to traffic keys rather than master key (both places).*
>
>

Yes, I think you are right. New text will be:
*In some routing protocols traffic keys are derived by the routing protocol
from a master key. In this case, KMP is responsible for the master key
generation. In other cases, there are only traffic keys (and no master
keys), and in such a case KMP is responsible for the traffic key generation.
*
*
*
*Gregory.*
*
*
*-- SNIP --*

> --
----
IETF related email from
Gregory M. Lebovitz