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

[Chandrasekar Ramachandran <[e-mail]>]

I have addressed one DISCUSS on authentication and one outstanding COMMENT on the disclaimer for pre5378 work in draft-ietf-mpls-ri-rsvp-frr-20.

Thanks,
Chandra.


Juniper Business Use Only
> -----Original Message-----
> From: Roman Danyliw
> Sent: Friday, June 7, 2024 7:27 PM
> To: Chandrasekar Ramachandran ; The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-ri-rsvp-frr-18:
> (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> Hi!
>
>
> Juniper Business Use Only
> > -----Original Message-----
> > From: Chandrasekar Ramachandran
> > Sent: Wednesday, June 5, 2024 8:22 AM
> > To: Roman Danyliw ; The IESG
> > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > 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 <[e-mail]>
> > > Sent: Wednesday, May 29, 2024 2:37 AM
> > > To: The IESG <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]
> > > 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/s
> > > ta
> > > 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-i
> > > et
> > > 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/mpls
> > /DQluEtXhVh06Urwqb7ncc3X3dUE/__;!!NEt6yMaO-gk!C6z2tYbdRJADJib2Th-
> BnxCV
> > nlEmo0Xtw9EPxJkdxVVjmxEnESzk0Ht49d3VWbHwrLpEtOrO$
> > ), 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/mpls/DQl
> uEtXhVh06Urwqb7ncc3X3dUE/__;!!NEt6yMaO-gk!C6z2tYbdRJADJib2Th-
> BnxCVnlEmo0Xtw9EPxJkdxVVjmxEnESzk0Ht49d3VWbHwrLpEtOrO$ .
> >
> > 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