Re: [OSPF] Gen-ART review of draft-ietf-ospf-hmac-sha-05

[Acee Lindem <[e-mail]>]

On Aug 13, 2009, at 8:07 PM, <[e-mail]> wrote:

> The -06 version of this draft has resolved all of the
> comments from the Gen-ART review of the -05 version.
>
> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: Black, David
>> Sent: Monday, July 20, 2009 10:20 AM
>> To: 'Gen Art'; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Cc: Black, David; Acee Lindem; Abhay Roy; Ross Callon; Adrian
>> Farrel; [e-mail]
>> Subject: Gen-ART review of draft-ietf-ospf-hmac-sha-05
>>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Please resolve these comments along with any other Last Call
>> comments you may receive.
>>
>> Document: draft-ietf-ospf-hmac-sha-05
>> Reviewer: David L. Black
>> Review Date: July 20, 2009
>> IETF LC End Date: July 20, 2009
>>
>> Summary:
>>
>> This draft is basically ready for publication, but has nits
>> that should be fixed before publication.
>>
>> Comments:
>>
>> This draft extends OSPFv2 cryptographic authentication to use
>> keyed HMACs based on the NIST secure hash standard family of
>> hashes (SHA-*).  The draft is solidly written, and is a
>> reasonably straightforward application of HMAC and the SHA-*
>> hashes to OSPFv2.  The draft is in good shape - all of my
>> comments are minor.
>>
>> I wonder whether the "SHOULD" requirement for implementation
>> in Section 3 ought to include HMAC-SHA-224 and HMAC-SHA-384.
>> I would have stated requirements for these two hashes as "MAY"
>> in order to encourage use of either HMAC-SHA-256 or HMAC-SHA-512
>> when HMAC-SHA-1 is insufficient, but this is a judgment call.
>> To avoid confusion, this is a request that the authors think
>> about this topic; it is *not* a comment that the requirement
>> needs to be changed.  If the authors believe that the current
>> "SHOULD" requirements for these two hashes are the right
>> approach, that is acceptable to me.
>>
>> In Section 3.2, it would be useful for the draft to say that an
>> OSPFv2 Security Association is not set up inband via OSPFv2, in
>> contrast to an IPsec Security Association created via IKE.  Among
>> the reasons that this should be done is that the term "OSPFv2
>> Security Association" is introduced in this draft - that term
>> does not occur in RFC 2328, even though Section D.3 of RFC 2328
>> defines an abstraction for which "OSPFv2 Security Association"
>> is an appropriate name.  I recommend stating that this term is
>> new to this draft.
>>
>> The mention of IP Security in the next to last paragraph of
>> the Security Considerations (section 4) should cite an
>> informative reference, RFC 4301 would be appropriate.
>>
>> idnits 2.11.12 did not find any issues.
>>
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> [phone]             FAX: [phone]
>> [e-mail]        Mobile: [phone]
>> ----------------------------------------------------
>>