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.
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.
(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.
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.
(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.
We'll consider a more normative update for BMP transport security in
working group discussion.
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".
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.
-- 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%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
_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
