Hi Hemant/Jeff, 

Thank you for the effort put in this document.

Please find below some comments that I prefer we discuss early in the process 
rather than late:

(1) Do we need another PS document for the specific use of TCP-AO with BMP? I'm 
asking the question given that rfc5925#section-1.2 already says:

   >> TCP-AO SHOULD be implemented where the protection afforded by TCP
   authentication is needed, because either IPsec is not supported or
   TCP-AO's particular properties are needed (e.g., per-connection
   keys).
 
I note that the reco in the draft covers both the "use" and "support", though. 
The "use" part smells more like a BCP?

(2) BTW, the reco in the draft **seems** to conflict with parts of the 
applicability in rfc5925#section-1.2:

draft-ietf-grow-bmp-tcp-ao:
   The implementation and use of TCP-AO to protect BMP session is
   RECOMMENDED in circumstances where the session might not otherwise be
   protected by alternative mechanisms such as IPsec.
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Vs.

rfc5925:
   TCP-AO is not intended to replace the use of the IPsec suite (IPsec
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
   and Internet Key Exchange Protocol (IKE)) to protect TCP connections
   [RFC4301][RFC4306].

It would be better to tweak the reco text to adhere to the applicability scope 
in rfc5925 not weaking it. For example,

NEW:
   The use of TCP-AO to protect BMP session is
   RECOMMENDED per the applicability scope in Section 1.2 of [RFC5925].

Note that you have it right in Section 4:

   TCP-AO is not intended as a direct substitute for IPsec, nor is it
   suggested as such in this document.

(3) The document is tagged as it updates RFC 7854, but I don't see which part 
this is amending/extending. Even for IPsec, RFC7854 uses this wording: 

   Where the security considerations outlined above are a concern, users
   of this protocol should use IPsec [RFC4303] in tunnel mode with pre-
   shared keys.

Please note also that the base TCP spec (RFC9293) discusses TCP-AO in 
https://datatracker.ietf.org/doc/html/rfc9293#section-7.

One minor comment about the motivation section: 

* " However, the security
   considerations associated with BMP have become increasingly critical
   in light of evolving threats."

Can we please explicit these threats or simply add pointers?

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : internet-dra...@ietf.org <internet-dra...@ietf.org>
> Envoyé : dimanche 23 février 2025 11:04
> À : i-d-annou...@ietf.org
> Cc : grow@ietf.org
> Objet : I-D Action: draft-ietf-grow-bmp-tcp-ao-01.txt
> 
> 
> Internet-Draft draft-ietf-grow-bmp-tcp-ao-01.txt is now available. It
> is a work item of the Global Routing Operations (GROW) WG of the IETF.
> 
>    Title:   TCP-AO Protection for BGP Monitoring Protocol (BMP)
>    Authors: Hemant Sharma
>             Jeffrey Haas
>    Name:    draft-ietf-grow-bmp-tcp-ao-01.txt
>    Pages:   5
>    Dates:   2025-02-23
> 
> Abstract:
> 
>    This document outlines the utilization of the TCP Authentication
>    Option (TCP-AO), as specified in [RFC5925], for the authentication
> of
>    BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854].
>    TCP-AO provides for the authentication of BMP sessions established
>    between routers and BMP stations at the TCP layer.
> 
> Discussion Venues
> 
>    This note is to be removed before publishing as an RFC.
> 
>    Source for this draft and an issue tracker can be found at
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fhmntsharma%2Fdraft-hmntsharma-bmp-tcp-
> ao&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe4646df6
> 308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63875901898
> 8483616%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> ata=IqYGSAQozEB4BrmhmXVXK8IPuo8Ase%2FnCrI2SIbV708%3D&reserved=0.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-bmp-tcp-
> ao%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe4646
> df6308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63875901
> 8988498031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA
> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
> &sdata=uNPUGMNoxYr1tFeBjg5PiOfPEJwZXjRyRKe2QWjzw6k%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-grow-bmp-tcp-ao-
> 01.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe46
> 46df6308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638759
> 018988505603%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=zLKUUJy1RlcC0at1zXU1uGSqII3pRvRAEjQbJC4GNFc%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-grow-bmp-tcp-ao-
> 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe4646df6
> 308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63875901898
> 8513002%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> ata=PXvLHVFrb%2BZ2aZv9NzokH9dRxlwngclKuo8ghSeoJmE%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> I-D-Announce mailing list -- i-d-annou...@ietf.org To unsubscribe send
> an email to i-d-announce-le...@ietf.org
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

Reply via email to