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

From: <[email-masked]>
Date: Thu, 13 Aug 2009 20:07:37 -0400

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'; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: Black, David; Acee Lindem; Abhay Roy; Ross Callon; Adrian 
> Farrel; [email-masked]
> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>