Subject: [mpls] Re: Roman Danyliw's Discuss on draft-ietf-mpls-ri-rsvp-frr-18: (with DISCUSS and COMMENT)
From: Roman Danyliw <[email-masked]>
To: Chandrasekar Ramachandran <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 7 Jun 2024 13:56:34 +0000
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>

Hi!

> -----Original Message-----
> From: Chandrasekar Ramachandran
> Sent: Wednesday, June 5, 2024 8:22 AM
> To: Roman Danyliw ; The IESG
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-ri-rsvp-frr-18:
> (with DISCUSS and COMMENT)
> 
> Warning: External Sender - do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 
> Please refer inline (prefixed [CR]) for responses.
> 
> Thanks,
> Chandra.
> 
> 
> Juniper Business Use Only
> > -----Original Message-----
> > From: Roman Danyliw via Datatracker <[email-masked]>
> > Sent: Wednesday, May 29, 2024 2:37 AM
> > To: The IESG <[email-masked]>
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > Subject: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-ri-rsvp-frr-18:
> > (with DISCUSS and COMMENT)
> >
> > [External Email. Be cautious of content]
> >
> >
> > 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
> > tem
> > ents/handling-ballot-positions/__;!!NEt6yMaO-
> > gk!G9rzzTtk1jM0eBeHTMYsdLgilxZEHzdBz3G8bmjPDat2PCQy-S-
> > xrRsjoiNFqQZXR_IIRRYpmZKExw$
> > for more information about how to handle DISCUSS and COMMENT
> > positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> > f-mpls-
> > ri-rsvp-frr/__;!!NEt6yMaO-
> > gk!G9rzzTtk1jM0eBeHTMYsdLgilxZEHzdBz3G8bmjPDat2PCQy-S-
> > xrRsjoiNFqQZXR_IIRRawJCD8lA$
> >
> >
> >
> > ----------------------------------------------------------------------
> > 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.
> >
> 
> [CR] The initial versions of the draft did not explicitly recommend
> authentication mechanisms and only contained generic text taking cue from
> existing RFCs in RSVP.
> Subsequent to your comments in 2019 (mail thread url -
> https://mailarchive.ietf.org/arch/msg/mpls/DQluEtXhVh06Urwqb7ncc3X3dUE/
> ), the sentence "When using RSVP Cryptographic Authentication [RFC2747],
> more robust algorithms [RFC2104] [FIPS-180-3] SHOULD be used when
> computing the keyed message digest where possible" was introduced without
> explicitly specifying the algorithms.
> 
> Will the following taking from your original recommendation be good? FIPS-
> 180-3 document has been superseded by FIPS-180-4 and hence the change in
> reference from your original recommended NEW text in
> https://mailarchive.ietf.org/arch/msg/mpls/DQluEtXhVh06Urwqb7ncc3X3dUE/.
> 
> OLD:
>    The security considerations pertaining to [RFC2961], [RFC4090],
>    [RFC8370], [RFC8796] and [RFC5920] remain relevant.  When using RSVP
>    Cryptographic Authentication [RFC2747], more robust algorithms
>    [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed
>    message digest where possible.
> 
> NEW:
>    The security considerations pertaining to the original RSVP protocol
>    [RFC2205], [RFC3209] and [RFC5920] remain relevant.  When using
>    RSVP Cryptographic Authentication [RFC2747], more robust algorithms
>    such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA-512
>    [RFC2104][FIPS-180-4] SHOULD be used when computing the keyed
>    message digest where possible.

Yes, that new text would address my feedback.

Thanks,
Roman