Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols
RFC 6094

Note: This ballot was opened for revision 04 and is now closed.

(Ron Bonica) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2010-09-29 for -)
Moved one small point from my previous Discuss. WOuld be nice to get it fixed.

You have caught most cases of ...

   In order for ... implementations to interoperate, they must support 
   one or more authentication schemes in common.

... with good change to include "with the use of security"

However, I still see issues in sections 2.2 (first line), 3.2 (first line), 5.2 (first line)

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2010-09-22 for -)
For consistency, add citations to the defining RFCs that define the use of 
HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 in the various routing protocols; e.g.,

   Implementations may start providing support for HMAC-SHA-256/HMAC-
   SHA-384/HMAC-SHA-512 [RFC5310] as these algorithms may be necessary in the 

at the end of section 3.2

(Lars Eggert) No Objection

Comment (2010-09-22 for -)
INTRODUCTION, paragraph 3:
>            Cryptographic Authentication Algorithm Implementation
>                    Best Practices for Routing Protocols

  It is odd to see the term "best practices" in the title of a document
  that is not actually targeted as a BCP. Plus, the contents of the
  document aren't best practices, they are rather suggestions to
  implementors to avoid potential future interoperability issues.
  Suggest to reword the title.

Section 4.1, paragraph 4:
>    all conformant implentations MUST support this.

  Nit: s/implentations/implementations/

Section 11.1, paragraph 2:
>    [ISO]       "Intermediate system to Intermediate system routeing

  Nit: s/routeing/routing/

(Russ Housley) No Objection

Comment (2010-09-19 for -)
  Two spellings are used: "Null authentication" and "NULL
  authentication".  Please pick one. 

  In the Introduction, I think it is better to talk about the overall
  technique before particular algorithms like MD5.  Below I suggest
  rewording for 3rd and 4th and 5th paragrahs of the introduction.
    In a cryptographic authentication scheme, routers share a secret
    key which is used to generate a message authentication code for
    each of the protocol packets.  Today, message authentication codes
    often use a keyed MD5 digest.  The recent escalating series of
    attacks on MD5 raise concerns about its remaining useful lifetime.
    These attacks may not necessarily result in direct vulnerabilities
    for keyed MD5 digests as message authentication codes because the
    colliding message may not correspond to a syntactically correct
    protocol packet.  There is a however a need felt to deprecate MD5
    in favor of stronger message authentication code algorithms.

(Tim Polk) (was Discuss) No Objection

Comment (2010-09-23)
I support Sean's discuss issue #4

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2010-09-23)
1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.  Keep the 2nd (that's where the RFC editor will put it).

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.
4) Sec 6: Is there something missing from the end of this sentence maybe "packet": 

   If the Address Family Identifier of the 
   first (and only the first) entry in the message is 0xFFFF, then the 
   remainder of the entry contains the authentication.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no