<?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.5 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-hmntsharma-bmp-tcp-ao-02" category="info" submissionType="independent" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.19.2 -->
  <front>
    <title>TCP-AO Protection for BGP Monitoring Protocol (BMP)</title>
    <seriesInfo name="Internet-Draft" value="draft-hmntsharma-bmp-tcp-ao-02"/>
    <author fullname="Hemant Sharma">
      <organization>Vodafone</organization>
      <address>
        <email>hemant.sharma@vodafone.com</email>
      </address>
    </author>
    <date year="2024" month="February" day="10"/>
    <area>Ops &amp; Management</area>
    <workgroup>GROW</workgroup>
    <keyword>BMP Security</keyword>
    <keyword>TCP-AO for BMP</keyword>
    <abstract>
      <?line 28?>

<t>This document outlines the utilization of the Transmission Control Protocol - Authentication Option (TCP-AO), as prescribed in RFC5925, for the authentication of Border Gateway Protocol Monitoring Protocol (BMP) sessions, as specified in RFC7854. The intent is to heighten security within the underlying Transmission Control Protocol (TCP) transport layer, ensuring the authentication of BMP sessions established between routers and BMP stations.</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 33?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The BGP Monitoring Protocol (BMP), as specified in RFC7854, advocates for the implementation of Internet Protocol Security (IPSec) from RFC4303 to address security issues concerning the BMP session between routers and the BMP station managing BGP route collection. This document underscores the use of Transmission Control Protocol - Authentication Option (TCP-AO) as the authentication mechanism ensuring 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 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) outlined in RFC7854 plays a crucial role in network management by allowing routers to share information about their BGP tables, helping operators monitor and troubleshoot their networks effectively. However, the security considerations associated with BMP have become increasingly critical in light of evolving cyber threats. This document proposes that these concerns be addressed by introducing a framework that utilizes the Transmission Control Protocol - Authentication Option (TCP-AO), specified in RFC5925, to safeguard BMP sessions.</t>
      <t>Extending this security measure to BMP helps mitigate risks associated with unauthorized access, tampering, and other potential security vulnerabilities. By integrating TCP-AO into BMP implementations, network operators can establish a more resilient and trustworthy foundation for BGP monitoring activities.</t>
      <t>TCP-AO is not intended as a direct substitute for IPSec, nor is it suggested as such in this document.</t>
      <t>As outlined in section "3.2. Connection Establishment and Termination" of RFC 7854, BMP operates as a unidirectional protocol, meaning no messages are transmitted from the monitoring station to the monitored router. Consequently, BMP lacks an effective means of tracking a session between the router and the station. It relies on the underlying TCP session, supported by TCP keepalives (RFC1122), to maintain session activity. Therefore, it is recommended to authenticate the end-to-end TCP session between the router and the BMP station using TCP-AO.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security of the BMP session gets a boost with TCP-AO, seamlessly implemented over the existing TCP transport, ensuring heightened protection without any additional load.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <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>
    <?line 58?>

<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 lacks the same level of protection within this context.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6VX72/bNhD9rr/i4AJDAkRGm7bYZmDAnKw/AixL0AbrZ1o6
W0QoUiMpJ96w/33vSEl20jYb1n6obYnk3b137x1TlmURdTS8oNnN+XW5vKJr
7yJXUTtLa+fp7N01XTqro/PabtJbVzlDR2eX18ezolKRN87vFqTt2hVF7Sqr
WhxXe7WOZdPaGBrlW1Wu2q6MVVcqVz4/LUK/anUIiBJ3HcvumjvGfzYSPSNl
gkNKB09nJzTjOqWhjPy4WJ7hAxnOLj7cvJ0Vtm9X7BdFjYwWReVsYBv6sCi2
C3pZKM9qQVddoO/oUlm14RaHFnfO326867sFvftw9am45R0e1YuCSkKB9JGr
3uu4k98DPgmUy+uiUH1snJelBeHfujcml/6eW4UyPqa60zvnN8rqP5WguqDf
Xa3WznJ6hbXaLKhJe+YZq5+3w4p55dqisA7Pot6iLAF5+kEf3p6//vH0df72
/Q+vXy2KoixLUqsQvapiUdw0OhA46aVacn002nKg2DD1UZshJXLr9OjGKxsG
Wugc1HgQPTFe0hIV4xxd5V1XXfo4ysAcn5AK1HkOldcrrkHpmOBJAk0iqIcn
IO4Z4GZP78Dandrto3215yhwSjCkeKHjSq/1FE5QmNMNQmkbpWbUHx3g1ZsG
v7E5E0p3OjbYkpBAg3mzk1BPIyCVHlOUNZ3zkYzasT8h6bOU6FcqRB+NOROH
qFZGhwYZrzjeMXJC/0X2gZSt8+KY9oZ5kelsdV0bLopndCEJ1X1Sp5DLT8vz
qwjhRb11ot0wUaPbziRRTIkjGnvLcX/qKAc6urjG92Nae9fKoa9ePn8pOKu6
RgOEPcyAskcQyLHCWSNIB5B8EYVpzZBMK4qVzVJuWogTjck2JXQfdnmiM1TO
j40eWKr5tuYWJL9Ab8tVA2WHdt8EsKsyuhIf/9YLY+Vy7hPVh/loPahSjDEt
qBqnq1TYoyjCp6xfqQDOQZ94HHSZCwU1fdVINQKlRPv1l+s5LYFnC+3ioABv
oVqHqs9QCXRTeByz1fUDcc+lMf/H7PgP/Tsa1mHrUgfVAQeqfF9hFAA5I2Kf
Km0nd6fVDngZdycnjwCjScVkmSYrRbJqhbcCq85Ji0YZBtOw6WSz69grpBio
zblmnnCmrGucGzcPSUDn67UAsWWzm9N7d8dbcQohbpKGjChg6TPJoCQ4FBRR
rXhT6oBGgYsVgxvJt8IMC0jHYC9OAOFGCjdibUITb53ZSrrVDpMQwbA+hsfy
AIWdC0kbKqUdeJSntOQoYfGnnZhoMhw5VUHtmG8J5LQ3T5BBZd86Ox7bVJ4b
wpZa86ZXvn4gHnTdm3sYep0tRR9YTguUehCMvQlDcAjegNcG4JLX4fZzsHub
pznKgWyrClEQXLXgHQFOEt0OBXjqnIwVabwp4LY3FjSugEbUDMDPEnC8EWpl
qAzysUNGD50WgcbW3bdZpex+VAD5Fm5GoAUhhMPcfX2QbbHZQWwwPfVAd+1e
VEoaMacG0U1atujaNCRFz0okVWuPpoVD4P6go7isnJasHkniK3Zpeb/ZILm8
K9lJGqQHTYY4y/BAvWGwhdnL+elc+sMOD96MVbZjYTfsW21TNTNpazQD5aEl
4GWMOOSMe6tz0lgMSkaXO5EmSNPGOnwNAY6A5dIUuU2jZJ+Gl/TuAVbjxInu
8A0WZ/9IqQf+o0eyZpczMqqSjrJ7zafoId2qcA27zeJ5PO/2rj+Z/hB8ThcR
ZINqnPH5FeV8UgFU03dyE8lilTe3zJ0yyCHQEYB78eL09DjJCNdMNFxiIucx
dMUu3ZY8g2k+EXZBoxfHaXNjyFDfS5dTNgcj7iCbpyo7HOZ92IsiDY/pVnH+
wBHzgJhUNtxRD68OG47SBCvnQsw6zqcCF1YtnDnAKie1oRi35XzZ4XsdRm3u
L3QHV7nxwohN3X6oSQyZFMruxCf10HbGqTpVcrH8bfmFKg7tt1GivLxSVQ/u
eSv0ipyyrG6tuzNcb2RHKP5a5L9tuP5ptsYFgGd/Pz5VpwZEamlUDFDxvdgX
w9oDbVRSImaC6zfNHpR0qbrEDeBTozFHB3eYPDcMricwTVeIw7ZPbYupQAYT
zkjkR3CN1oARE/kezvAPmxkYnnMOAAA=

-->

</rfc>
