Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.txt

Should we be clearer somewhere that inapplicable fields may be omitted? 
(it is a conceptual table, I think we can allow conceptually optional 
elements.)
Yours,
Joel

On 10/25/2012 7:24 PM, Brian Weis wrote:
> Hi Russ,
>
> On Oct 23, 2012, at 3:32 PM, Russ Housley wrote:
>
>> Uma:
>>
>>>>>>>> I have worked through the use of pairwise keys (used in just one direction or both directions)
>>>>>>>> as well as multicast keys.  The current table supports all of these cases. I do not understand
>>>>>>>> why you want two separate tables.  Clearly, you are thinking about this differently than I am.
>>>>>>>> Can you explain how two tables will make implementation easier?
>>>
>>> [Uma]:  Let's focus on only from the key life time perspective. Some IGPs do require life times in the
>>>        specified format to make key transition easier.  But, I don't see how to fit these 4 parameters
>>>        for pair wise keys. For e.g. for TCP based pair-wise keys, when new master key is negotiated by
>>>        KMP, TCP-AO makes coordinated key transition with the peer. Not at all based on the key table
>>>        time entries specified. In that sense the entries defined today useful and enable protocols
>>>        e.g., group-key RPs, who don't have a defined way of key transition and more over do security
>>>        by themselves (make sense there).
>>>
>>>        Now, I stepped back to think on how to use for pair-wise protocols and not able to connect the
>>>        dots here. Do you see these are operator inputs or KMP negotiated and how one would use these entries?
>>
>> You will note that earlier drafts only had notBefore and notAfter.  The additional one were added because some IGPs need them.
>>
>> I see no way to move forward and address both comments.
>
> The draft appears to be silent as to whether fields in the key table are required, but my belief is that not all fields are required to be used for all keys. As such, if a KMP for TCP-AO adds a row to the key table, and some fields in that row are not required, then it simply does not need to specify their use. Is that not correct?
>
> Thanks,
> Brian
>
>> Russ
>> _______________________________________________
>> karp mailing list
>> karp@ietf.org
>> https://www.ietf.org/mailman/listinfo/karp
>
>