[mpls] Re: Deb Cooley's No Objection on draft-ietf-mpls-ri-rsvp-frr-18: (with COMMENT)

[Chandrasekar Ramachandran <[e-mail]>]

Please see inline (prefixed [CR]) for responses.

Thanks,
Chandra.


Juniper Business Use Only
> -----Original Message-----
> From: Deb Cooley via Datatracker <[e-mail]>
> Sent: Friday, May 24, 2024 8:33 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Nicolai Leymann <[e-mail]>; [e-mail]
> Subject: Deb Cooley's No Objection on draft-ietf-mpls-ri-rsvp-frr-18: (with
> COMMENT)
>
> [External Email. Be cautious of content]
>
>
> Deb Cooley has entered the following ballot position for
> draft-ietf-mpls-ri-rsvp-frr-18: No Objection
>
> 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/statem
> ents/handling-ballot-positions/__;!!NEt6yMaO-
> gk!CJYdxnI_JIqZNDVpogierQqFYVP3_GrNU_RfmWWvRJO1kIFDo0uHMhY865Yt
> R-bUrmymbB9coLsEdQ$
> 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-ietf-mpls-
> ri-rsvp-frr/__;!!NEt6yMaO-
> gk!CJYdxnI_JIqZNDVpogierQqFYVP3_GrNU_RfmWWvRJO1kIFDo0uHMhY865Yt
> R-bUrmymbB9P6oEp5Q$
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1.  FIPS 180 has been up issued in 2015:
> https://urldefense.com/v3/__https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS
> .180-4.pdf__;!!NEt6yMaO-
> gk!CJYdxnI_JIqZNDVpogierQqFYVP3_GrNU_RfmWWvRJO1kIFDo0uHMhY865Yt
> R-bUrmymbB8VXMMewQ$  .

[CR] Reference is corrected in draft-ietf-mpls-ri-rsvp-frr-20.

> 2.  Security Considerations:  "When using RSVP Cryptographic Authentication
> [RFC2747], more robust algorithms [RFC2104] [FIPS-180-3] SHOULD be used
> when computing the keyed message digest where possible."  This sentence is
> confusing to me.
>    a.  It would seem like the 'SHOULD' should be a 'MUST'?  RFC2747 uses
>    HMAC-MD5 which is well beyond its end of life, or HMAC-SHA1, which isn't
>    deprecated yet, but NIST has plans to deprecate. b.  In addition, the
>    position of the references to RFC 2104 and FIPS 180 in the sentence adds to
>    the confusion - I would suggest moving them to the end of the sentence.

[CR] Please refer to the discussions related to this text in 2019 from the thread https://mailarchive.ietf.org/arch/msg/mpls/DQluEtXhVh06Urwqb7ncc3X3dUE/ and the latest email thread on the same from https://mailarchive.ietf.org/arch/msg/mpls/119-r_6cfiyVOlg8A1_j7tfHl6o/.

> 3.  general, and only because there is another comment on this:  'let us
> assume' is commonly used in mathematical proofs.  However, I have no idea
> how common it is in the IETF RFCs, much less routing RFCs.

[CR] This has been addressed in draft-ietf-mpls-ri-rsvp-frr-20.