[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



From: <Black_David at emc.com>
Date: July 22, 2009 8:40:47 PM EDT
To: <rja at extremenetworks.com>
Cc: <ospf at ietf.org>, <Black_David at emc.com>
Subject: RE: Gen-ART review of draft-ietf-ospf-hmac-sha-05


Ran,

This is fine with me - about the level of requirement for
SHA-224 and SHA-384, I originally wrote:

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.

Thinking has clearly happened ;-), and I have no problem with
a result that that the requirement level will not be changed
because doing so would reduce consensus. 

Thanks,
--David 

-----Original Message-----
From: RJ Atkinson [mailto:rja at extremenetworks.com] 
Sent: Wednesday, July 22, 2009 5:55 PM
To: Black, David
Subject: Re: Gen-ART review of draft-ietf-ospf-hmac-sha-05

All,

On  22 Jul 2009, at 11:31, Bhatia, Manav (Manav) wrote:
Given that SHA-224 (and perhaps SHA-384) is not even present in all
crypto libraries we could, if others don't see a problem, move this
from a SHOULD to a MAY.

All of the key-lengths for SHA-1 and SHA-2 are available in
at least some freely available crypto libraries, specifically
including both SHA-224 and SHA-384.

(ASIDE:  Commonly used search engines can be used to find such
libraries.
Choice of which libraries, if any, to use is obviously implementer's
choice.)

Making that change to "MAY" would reduce consensus, as compared
with retaining the current "SHOULD" text, so it is best to keep
the current language as-is.

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

Yup, sounds reasonable. We could add this too.

I made that edit about an hour after David's note was originally sent.

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.


Yup, this can also be done.

Again, I made that edit about an hour after David's note was  
originally sent.

Cheers,

Ran Atkinson
(who is the active document editor for this draft)