Hi Jeff, Thanks for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Jeffrey Haas <jh...@pfrc.org> > Envoyé : lundi 3 mars 2025 01:57 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; draft- > ietf-grow-bmp-tcp...@ietf.org > Cc : grow@ietf.org > Objet : Re: [GROW] Re: I-D Action: draft-ietf-grow-bmp-tcp-ao-01.txt > > > Med, > > Thanks for your review. > > On 2/27/25 04:49, mohamed.boucad...@orange.com wrote: > > 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? > > This is a quite fair observation. The motivation for the document is > largely to lend the weight of WG review and what would be an otherwise > trivial update to BMP in order to recommend TCP-AO as a > transport. BCP status would be one possible way this document > completes its life. > [Med] Cool! > While I agree with you that RFC 5925 is a good catch-all for "use TCP- > AO", implementers tend to look for documents targeting a given > transport for the protocol as the recommended practice. Additionally, > operators also make use of RFC status to press for particular > implementation profiles. > > This draft is thus a light-weight patch to accomplish those goals. [Med] Sounds good to me. > > > > > (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. > > We'll consider how to address your point. > [Med] Thanks. > The headache we are dealing with in practice is that IPsec remains > unpopular for protecting stream-based routing protocols. Dealing with > why this is the case is rather out of scope for our particular effort, > but perhaps consideration over libations at IETF. [Med] I hear you. > > > > > (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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc9293%23section- > 7&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca199801ca02549f55752 > 08dd59ee589e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638765602427 > 819981%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > ta=Xz1eHKQY6WoeURIiBlB9MAY5JZfbrnQXM454q58zz80%3D&reserved=0. > > We'll consider a more normative update for BMP transport security in > working group discussion. [Med] Looking forward for that discussion to happen. BTW, as I see there is also draft-hmntsharma-bmp-over-tls, it would be good for the discussion to explore which posture to adopt/recommend when it comes to the various security features. I'd hope this will be pragmatic and be driven by the deployment reality. > > A historical note: During much of the development of the BMP RFC, > transport security wasn't heavily considered. TCP-AO was long > specified by that point but hadn't gotten much deployment. The BMP > RFC thus completed its review with a light "sprinkling" of IPsec in > order to address security review considerations. > > TCP-AO getting deployment has helped to motivate updating BMP to > recommend its deployment as practicable rather than nodding in the > direction of, "well... you *could* use IPsec". > [Med] :-) > Note that we're also seeing introduction of documents covering QUIC > across IETF for similar reasons. > > > > > 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? > > For my own part, I can't supply appropriate IETF citable text here. I > suspect if it's critical I can find some appropriate CERT-style > documentation. > > The general consideration is that BMP is not only used as a monitoring > tool, but a telemetry-supplying tool for software defined networking > applications. Not only does this provide a tempting source of > centralized routing information that has strong operational privacy > considerations, it's also a tempting target to further attack networks > that leverage BMP for its centralized control plane. Minimally, this > increases the necessity for integrity and authentication - properties > that are supplied by BMP. Operators requiring privacy must leverage > IPsec, or consider transports such as TLS, QUIC, or even ssh. > > I think were we to consider an update to address your concern, it'd be > a somewhat general note that integrity and authentication are > important for such deployments. > [Med] I like this approach. > -- Jeff > > > > > > 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%2Fgit > >> > h%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca199801ca02549f5 > >> > 575208dd59ee589e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387656 > >> > 02427833291%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL > >> > jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C > >> > %7C&sdata=OZ7tNJ3DmMvG9faZlDpQWJ1v7B3PCIf%2FTIiMIXGMVZw%3D&reserved=0 > >> ub.com%2Fhmntsharma%2Fdraft-hmntsharma-bmp-tcp- > >> > ao&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe4646df > >> 6 > >> > 308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387590189 > >> 8 > >> > 8483616%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > >> D > >> > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > >> d 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%2Fdat > >> > a%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca199801ca02549f5 > >> > 575208dd59ee589e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387656 > >> > 02427841493%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL > >> > jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C > >> > %7C&sdata=CqLvUsQTqKGHo7xkT3Xp1ii5gU72Y8osrzpSSdiCZ%2BU%3D&reserved=0 > >> tracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-bmp-tcp- > >> > ao%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe464 > >> 6 > >> > df6308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387590 > >> 1 > >> > 8988498031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj > >> A > >> > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7 > >> C > >> &sdata=uNPUGMNoxYr1tFeBjg5PiOfPEJwZXjRyRKe2QWjzw6k%3D&reserved=0 > >> > >> There is also an HTML version available at: > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww% > 2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca199801ca02549f5575 > 208dd59ee589e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63876560242 > 7849574%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=ScvlwEyqUgEnRkhtZJnc3dOYrtJpsNqftBf0oTVXRKE%3D&reserved=0. > >> ietf.org%2Farchive%2Fid%2Fdraft-ietf-grow-bmp-tcp-ao- > >> > 01.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe4 > >> 6 > >> > 46df6308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63875 > >> 9 > >> > 018988505603%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw > >> L > >> > 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%2Faut > >> > h%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca199801ca02549f5 > >> > 575208dd59ee589e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387656 > >> > 02427857661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL > >> > jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C > >> > %7C&sdata=7Y%2BpxRfRKRhZpMkN5WDEq%2BQMWzYFA6P%2FO4VHoW%2Fz%2BTU%3D&re > >> served=0 > >> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-grow-bmp-tcp-ao- > >> > 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3a5c85ed5afe4646df > >> 6 > >> > 308dd53f1860c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387590189 > >> 8 > >> > 8513002%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > >> D > >> > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > >> d > >> 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 ____________________________________________________________________________________________________________ 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
