<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 3.4.8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-grow-bmp-tcp-ao-03" category="std" submissionType="IETF" updates="7854" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="TCP-AO for BMP">TCP-AO Protection for BGP Monitoring Protocol (BMP)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-tcp-ao-03"/>
    <author fullname="Hemant Sharma">
      <organization>Vodafone</organization>
      <address>
        <email>hemant.sharma@vodafone.com</email>
      </address>
    </author>
    <author fullname="Jeffrey Haas">
      <organization>Juniper Networks</organization>
      <address>
        <email>jhaas@juniper.net</email>
      </address>
    </author>
    <date year="2026" month="January" day="22"/>
    <area>Ops &amp; Management</area>
    <workgroup>GROW</workgroup>
    <keyword>BMP Security</keyword>
    <keyword>TCP-AO for BMP</keyword>
    <abstract>
      <?line 45?>

<t>This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in <xref target="RFC5925"/>, for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in <xref target="RFC7854"/>. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/hmntsharma/draft-hmntsharma-bmp-tcp-ao"/>.</t>
    </note>
  </front>
  <middle>
    <?line 50?>

<section anchor="requirements-language">
      <name>Requirements Language</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119"/>
        <xref target="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.</t>
    </section>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>The BGP Monitoring Protocol (BMP), as specified in <xref target="RFC7854"/>, recommends the use of IPsec <xref target="RFC4303"/> to address security considerations concerning the BMP session between a router and the BMP station managing BGP route collection. This document suggests the use of the TCP Authentication Option (TCP-AO) as an authentication mechanism to ensure end-to-end authentication of BMP sessions between the routers and the BMP stations. TCP-AO is also the choice of authentication for TCP-based network protocols such as BGP and LDP. A comprehensive discussion of TCP-AO is provided in <xref target="RFC5925"/>.</t>
    </section>
    <section anchor="tcp-ao-protection-for-bgp-monitoring-protocol-bmp">
      <name>TCP-AO Protection for BGP Monitoring Protocol (BMP)</name>
      <t>The BGP Monitoring Protocol (BMP), defined in <xref target="RFC7854"/>, plays a crucial role in network management by allowing routers to share information about their BGP RIBs.  This helps operators monitor and troubleshoot their networks effectively. However, the security considerations associated with BMP have become increasingly critical in light of evolving threats. This document proposes that these threats be addressed by utilizing TCP-AO to safeguard BMP sessions.</t>
      <t>TCP-AO provides protection against spoofed TCP segments and helps protect the integrity of the TCP session.  Further, it provides for the authentication of session endpoints.  Similar to BGP, BMP can benefit from these security properties.</t>
      <t>TCP-AO helps protect the integrity of BMP session liveness at the TCP layer.  As outlined in <xref section="3.2" sectionFormat="of" target="RFC7854"/>, BMP operates as a unidirectional protocol, meaning no BMP messages are transmitted from the monitoring station to the monitored router.  BMP relies on the underlying TCP session, supported by TCP keepalives <xref target="RFC1122"/>, to prevent session timeouts from the station to the monitored router.</t>
      <section anchor="operational-recommendations-for-bmp">
        <name>Operational Recommendations for BMP</name>
        <t>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.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TCP-AO is not intended as a direct substitute for IPsec, nor is it suggested as such in this document.  The Security Considerations for TCP-AO in <xref section="11" sectionFormat="of" target="RFC7854"/> all apply to its application for BMP.</t>
      <t>TCP-AO may inhibit connectionless resets when session keys have been lost or changed.  This may cause BMP sessions to linger in some circumstances; however, BGP shares this consideration.</t>
      <t>In the presence of NAT, TCP-AO requires additional support as defined in <xref target="RFC6978"/>.</t>
      <t>TCP-AO does not provide for privacy for the BMP protocol's contents.  When this is desired, IPsec with Encapsulating Security Payload (ESP) can help provide for such privacy.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC5925">
          <front>
            <title>The TCP Authentication Option</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="R. Bonica" initials="R." surname="Bonica"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5925"/>
          <seriesInfo name="DOI" value="10.17487/RFC5925"/>
        </reference>
        <reference anchor="RFC7854">
          <front>
            <title>BGP Monitoring Protocol (BMP)</title>
            <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"/>
            <author fullname="R. Fernando" initials="R." surname="Fernando"/>
            <author fullname="S. Stuart" initials="S." surname="Stuart"/>
            <date month="June" year="2016"/>
            <abstract>
              <t>This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7854"/>
          <seriesInfo name="DOI" value="10.17487/RFC7854"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC1122">
          <front>
            <title>Requirements for Internet Hosts - Communication Layers</title>
            <author fullname="R. Braden" initials="R." role="editor" surname="Braden"/>
            <date month="October" year="1989"/>
            <abstract>
              <t>This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="3"/>
          <seriesInfo name="RFC" value="1122"/>
          <seriesInfo name="DOI" value="10.17487/RFC1122"/>
        </reference>
        <reference anchor="RFC4303">
          <front>
            <title>IP Encapsulating Security Payload (ESP)</title>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="December" year="2005"/>
            <abstract>
              <t>This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4303"/>
          <seriesInfo name="DOI" value="10.17487/RFC4303"/>
        </reference>
        <reference anchor="RFC6978">
          <front>
            <title>A TCP Authentication Option Extension for NAT Traversal</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <date month="July" year="2013"/>
            <abstract>
              <t>This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6978"/>
          <seriesInfo name="DOI" value="10.17487/RFC6978"/>
        </reference>
      </references>
    </references>
    <?line 92?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document is an outcome of the experiences gained through implementing BMP. While TCP-AO safeguards other TCP protocols, BMP currently lacks the same level of protection.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA51X224bORJ9768gFGA3A0iCL8km0WKBkRNnrIFtaW1nB/tI
dZfUHLPJHpItrTbQv+8pslu3bC4YP1h9IYtVp06dqh4MBllQQdNI9J7ezwbj
qZg5GygPyhqxsE5c/TITd9aoYJ0yy/jW5laLl1d3s596mZzPHa1Got0cd9zN
slwGWlq3GQllFjbLCpsbWeGUwslFGCgKi8HS2fVgXtWDkNcDaQdnl1lTF9jo
R+LN29evshe+mVfKe7gSNjWxrYJqwj8ThHghpPYWfh887fVFj4roq9R8Mxlf
4QdO9SYPTx97mWmqOblRxseMstwaT8Y3fpQhhMtMOpIjMa29+Iu4k0YuqYLR
bG3dM5xt6pH45WH6W/ZMGzwqRpkYcLDikfLGqbDh+xMcstMQJtdPH/+k78B0
JHwoMlW7kQiu8eHi7Ozd2UWWZbIJpXXsUSbwt2i0TnjfUCWB1mMpXSXjO+uW
0qj/Ss7wSPzLFnJhDcVXWKv0SJRxz9DHPT+v2hXD3FZf2v+VFgtHG3Ejpf8/
5n9tjKrJiXsKjKI/POb3Ent+/j2tGBoKWWYsTgxqhdyIh4/vL87P36Wrt+dv
XqWr1+8uXqcr5sgoy5hgR7vOzy8u0tWry7PLdPW3d2/eYu1gMBBy7oOTOU57
KpUXYGbDWRa2CVoZ8iKUJJqgdBuEsIv4CJkVY8CMtSpPb6Z1/HmZkv5TX0gv
fE25WigqwFbx+XPr8Xbbj5xgQ/LYCMx/s8aEp8gf/xXzDMN2O+yYVzu7UgXC
+MZx4GxnVJAPcq6VL2FyjiwRGQGuB3JeSFOkxSHuxYOwg0LLDbKWJUwrVRSa
suyFeKA/GuVi3XhxK82yQRUx1CRQNoLrxove3afHJ6Y4/4r7abx+uP7np8nD
9Qe+frwZ3972+lm66FY83kw/3X7YX+13vp/e3V3ff0ib8TQ7eXQ3/jd+OJze
dPY0md6Pb3sMYDhiAMpfBAsUwCnEXzsKAAWgA87cqXkC/QrBn79K2DNBt9ss
XjNFt1uxBtjpKGv0pr0FaBsh65qkg4lMai1yWasAFUhZLe3aoO4cDRnEiQnO
Fk0U4YTdNxnyTWL0hSNULgIsWmp7YhJMZp7ytJDLBJ4jdFkUDsQAO5KiCVZI
sMm1+cdtTs6wC2zqgEg77siWPRGC3aJEIFGxqPJujieug0mtU7sBhY/S4Zvl
Euw88vrHCpHxkOaU+RXlJaTJVxwpyz7SDVQGwQ7w87066eJjDw7r4yREvytE
hMIiHxfkpVV5DODkFC5SXj+XHpkzSSW5hmN6kYgmLzkaxotPu/0wG4oxQKvA
ThjyUD1RKJ83KQs4YX98KwWnShQp9iea/Q8xsaAFRPRLEtbQCwAictfk6G+A
UBMv6kKudu1WzFEqWts1m++QRsa4HZHYqT08lnO8ZXxV8vxhcgX4E4tK0mjj
tmbqWhioksspZbA614Sis9321g3I4WLBeKxIb4bixq5pRS7W71drQnpvERJL
xVqFMpKhlEjLnOuOPc4xVnhEAzmAjHDuNYeu1bIMnDFaWb1KNYWVwZ8WAvJY
Wx87UxJg1EK7FId0Rcv6vWkbFxtrM8zIyQVBh11xxGjQ4LRl1Hs2yKVUxqMI
a2sXMM1F52mZdJ1BTAC3OyJALJrLiNBBobanIS0fG4eHAFOFH2lSna6gNGsL
05zZR1UpDQlFTMh3P4aTS9YeA9oFsXC2avHZZYvBIxcUHQT8Hd8PZU2DCoYl
8YvWJ8TYd0NDy/fHFrzL4QXbOaA/m0xkJB/VSWDsKdAo4wbwoSv5PmRKRoE1
Nu6qcDgqw6fu5KTxlQpMti7Yjtq8p9PZYA/fYHGqI/jMJh1pwCFsErMG06fT
m5YyXeB9SE9dWxcSrfjNM1EtGQ+fSpvnLI4Nh0GMVlGyW9SCqggn+r2T3/MM
mvQCMt5WFQB56LpWW2a7iZpFSFW1jmLRCgH42DaIPeu79B5mE1V1MBlw0nLl
UGXwDo3Nc7dmlGO1px1VLFIDobDM3rXyXNid8QSO1IjAxAl032T22h07bRTd
7kNBvD+SkB0v4R6fxGQ0RRo9pEgsgTXMrSpwy2QootE+ljvepXbdMu2KR5/O
N1Ea6WtO7FoR+3FI5vPzIy6zNvMoAzEDyIrVADeH/QyA70utkhuYK9UcLkI4
TTKquaIgWhQi5mYHN2ZE36knHmsLCYJJxnRJRSfubDSXnPGjFg1/UIxL4hlL
eNbeo+z+XZSdnnO3iP3EJ4iOJB3OT1Jp1OyiSY37fvzU7/Bxacj1LL2q5Wtb
LmlcPO6B/PER2267vbCUEt3KYEStdmol881OETmyThT+Gj0MlFTwt5LazKo4
msKTot/Oc7EDXRsMl77RiAZFvcv3TG60lYV4ef2IrwrWTdbBIycib1pP0iQ6
vh9/ydaj7lRKDiatlHloW0v8LJjL/JmtjPNnY9eaitQ/ss+j9B1OxT96CwxJ
1NueWlVxgoM2xB7aNhT6DwRCUSxV7k/E4xcEZFnuFSFOl2AgYFKauoztWqBP
dRwFbTdmtZ2kcQ4GQGwNv9PY6fGRKzRIo9mHfX8cZv8DCKMeZDoRAAA=

-->

</rfc>
