[mpls] Roman Danyliw's Discuss on draft-ietf-mpls-ri-rsvp-frr-18: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-mpls-ri-rsvp-frr-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 5
   When using RSVP
   Cryptographic Authentication [RFC2747], more robust algorithms
   [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed
   message digest where possible.

I don’t intended to open the generic topic of RSVP authentication.  However, I
need help understanding the proposed guidance on cryptographic authentication.

RFC2104 specifies the core HMAC construction and HMAC-MD5

RFC2747 says “HMAC-MD5 is required as a baseline to be universally included in
RSVP implementations providing cryptographic authentication, with other
proposals optional”

FIPS-180-3 = specifies SHA-1, SHA-256, SHA-384, and SHA-512

What exactly is the recommendation on the “more robust algorithms … where
possible”?  Across all the referenced drafts, HMAC-MD5, -SHA1, -SHA256, -SHA386
and -SHA512 were cited.

Is this document intending to recommend MD5 and SHA1 as “robust algorithms”? My
recommendation would be that implementations using RSVP Cryptographic
Authentication SHOULD use HMAC-256/-386/-512.  Based on the RFC2747, HMAC-MD5
remains MTI.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Reese Enghardt for the GENART review.

Idnits reports:

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  == Unused Reference: 'RFC3936' is defined on line 1166, but no explicit
     reference was found in the text