<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-bfd-optimizing-authentication-13"
     ipr="trust200902" updates="5880">
  <front>
    <title abbrev="BFD Authentication Optimization">Optimizing BFD
    Authentication</title>

    <author fullname="Mahesh Jethanandani" initials="M."
            surname="Jethanandani">
      <organization>Kloud Services</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>mjethanandani@gmail.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Ashesh Mishra" initials="A" surname="Mishra">
      <organization>SES Networks</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <email>mishra.ashesh@gmail.com</email>
      </address>
    </author>

    <author fullname="Ankur Saxena" initials="A" surname="Saxena">
      <organization>Ciena Corporation</organization>

      <address>
        <postal>
          <street>3939 N 1st Street</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>ankurpsaxena@gmail.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Manav Bhatia " initials="M." surname="Bhatia ">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street/>

          <city>Bangalore</city>

          <code/>

          <country>India</country>
        </postal>

        <email>manav.bhatia@nokia.com</email>
      </address>
    </author>

    <date day="1" month="August" year="2021"/>

    <keyword>BFD</keyword>

    <keyword>authentication</keyword>

    <abstract>
      <t>This document describes an optimization to BFD Authentication as
      described in Section 6.7 of BFD RFC 5880. This document updates RFC
      5880.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Authenticating every <xref target="RFC5880">BFD</xref> control packet
      with a Simple Password, or with a <xref target="RFC1321">MD5
      Message-Digest Algorithm </xref> , or Secure Hash Algorithm (SHA-1)
      algorithms is a computationally intensive process. This makes it
      difficult, if not impossible to authenticate every packet - particularly
      at faster rates. Also, the recent escalating series of attacks on MD5
      and SHA-1 described in <xref target="SHA-1-attack1">Finding Collisions
      in the Full SHA-1 </xref> and <xref target="SHA-1-attack2">New Collision
      Search for SHA-1 </xref> raise concerns about their remaining useful
      lifetime as outlined in <xref target="RFC6151">Updated Security
      Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm
      </xref> and <xref target="RFC6194">Security Considerations for the SHA-0
      and SHA-1 Message-Digest Algorithm </xref>. If replaced by stronger
      algorithms, the computational overhead, will make the task of
      authenticating every packet even more difficult to achieve.</t>

      <t>This document proposes that only BFD control packets that signal a
      state change, a demand mode change (to D bit) or a poll sequence change
      (P or F bit change) in a BFD control packet be categorized as a
      significant change. This document also proposes that all BFD control
      packets which signal a significant change MUST be authenticated if the
      session's bfd.AuthType is non-zero. Other BFD control packets MAY be
      transmitted and received without the A bit set.</t>

      <t>Most packets that are transmitted and received have no state change
      associated with them. Limiting authentication to packets that affect a
      BFD session state allows more sessions to be supported with this
      optimized method of authentication. Moreover, most BFD control packets
      that signal a significant change are generally transmitted at a slower
      interval of 1s, leaving enough time to compute the hash.</t>

      <t>To detect a Man In the Middle (MITM) attack, it is also proposed that
      a BFD control packet without a significant change be authenticated
      occasionally. The interval of the BFD control packets without a
      significant change can be configured depending on the detect multiplier
      and the capability of the system. As an example, this could be equal to
      the detect multiplier number of packets.</t>

      <t>The rest of the document is structured as follows. Section 2 talks
      about the changes to authentication mode as described in <xref
      target="RFC5880">BFD</xref>. Section 3 goes into the details of the new
      Authentication Type.</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">BCP 14</xref> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>

      <section title="Terminology">
        <t>The following terms used in this document have been defined in
        <xref target="RFC5880">BFD</xref>.</t>

        <t><list style="symbols">
            <t>Detect Multiplier</t>

            <t>Detection Time</t>
          </list></t>

        <t>The following terms are introduced in this document.</t>

        <texttable style="full">
          <ttcol>Term</ttcol>

          <ttcol>Meaning</ttcol>

          <c>significant change</c>

          <c>State change, a demand model change (to D bit) or a poll sequence
          change (P or F bit).</c>

          <c/>

          <c/>

          <c>configured interval</c>

          <c>Interval at which BFD control packets are authenticated in the UP
          state.</c>
        </texttable>
      </section>
    </section>

    <section title="Authentication Mode  ">
      <t>The cryptographic authentication mechanisms specified in <xref
      target="RFC5880">BFD</xref> describes enabling and disabling of
      authentication as a one time operation. As a security precaution, it
      mentions that authentication state be allowed to change at most once.
      Once enabled, every packet must have Authentication Bit set and the
      associated Authentication Type appended. In addition, it states that an
      implementation SHOULD NOT allow the authentication state to be changed
      based on the receipt of a BFD control packet.</t>

      <t>This document proposes that the authentication mode be modified to be
      enabled on demand. Instead of authenticating every packet, BFD peers are
      configured for which packets need to be authenticated, and authenticate
      only those packets. Rest of the packets can be transmitted and received
      without authentication. For example, the two ends can be configured such
      that BFD control packets that indicate a significant change should be
      authenticated and enable authentication on those packets only. If the
      two ends have previously been configured as such, but at least one side
      decides not to authenticate a significant change packet, then the BFD
      session will fail to come up.</t>

      <t>This proposal outlines which BFD control packets need to be
      authenticated (carry the A-bit), and which packets can be transmitted or
      received without authentication enabled. A BFD control packet that fails
      authentication is discarded, or a BFD control packet that was supposed
      to be authenticated, but was not, e.g. a significant change packet, is
      discarded. However, there is no change to the state machine for BFD, as
      the decision of a significant change is still decided by how many valid
      consecutive packets were received, authenticated or otherwise.</t>

      <t>The following table summarizes when the A bit should be set. The
      table should be read with the column indicating the BFD state the
      receiver is currently in, and the row indicating the BFD state the
      receiver might transition to based on the BFD control packet received.
      The interesection of the two indicates whether the received BFD control
      packet should have the A bit set (Auth), no authentication is needed
      (NULL), most packets are NULL AUTH (Select) or the state transition is
      not applicable. The BFD state refers to the states in BFD state machine
      described in Section 6.2 of <xref target="RFC5880">BFD</xref>.</t>

      <t><figure align="center" title="Optimized Authentication Map">
          <artwork><![CDATA[       Read   : On state change from <column> to <row>
       Auth   : Authenticate BFD control packet
       NULL   : No Authentication. Use NULL AUTH Type.
       n/a    : Invalid state transition.
       Select : Most packets NULL AUTH. Selective (periodic) 
                packets authenticated.
      +--------+--------+--------+--------+
      |        | DOWN   | INIT   | UP     |
      +--------+--------+--------+--------+
      | DOWN   |  NULL  |  Auth  |  Auth  |
      +--------+--------+--------+--------+
      | INIT   |  Auth  |  NULL  |  n/a   |
      +--------+--------+--------+--------+
      | UP     |  Auth  |  Auth  | Select |
      +--------+--------+--------+--------+
]]></artwork>
        </figure></t>

      <t>If P or F bit changes value, the BFD control packet MUST be
      authenticated. If the D bit changes value, the BFD control packet MUST
      be authenticated.</t>

      <t>All packets already carry the sequence number. The NULL AUTH packets
      MUST contain the Type specified in Section 3. This enables a
      monotonically increasing sequence number to be carried in each packet,
      and prevents man-in-the-middle from capturing and replaying the same
      packet again. Since all packets still carry a sequence number, the logic
      for sequence number maintenance remains unchanged from <xref
      target="RFC5880">BFD </xref>. If at a later time, a different scheme is
      adopted for changing sequence number, e.g. <xref
      target="I-D.ietf-bfd-secure-sequence-numbers">Secure BFD Sequence
      Numbers</xref>, this method can use the updated scheme without any
      impact.</t>

      <t>Most packets transmitted on a BFD session are BFD UP packets.
      Authenticating a small subset of these packets, for example, a detect
      multiplier number of packets per configured interval, significantly
      reduces the computational demand for the system while maintaining
      security of the session across the configured interval. A minimum of
      Detect Multiplier packets MUST be transmitted per configured interval.
      This ensures that the BFD session should see at least one authenticated
      packet during that interval.</t>
    </section>

    <section title="NULL Auth Type">
      <t>This section describes a new Authentication Type as: <figure
          align="center" title="NULL Auth Type">
          <artwork><![CDATA[       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Auth Type   |   Auth Len    |  Auth Key ID  |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure> where:</t>

      <t>Auth Type: The Authentication Type, which in this case is TBD (NULL,
      to be assigned by IANA)</t>

      <t>Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes</t>

      <t>Auth Key ID: The authentication key ID in use for this packet. Must
      be set to zero.</t>

      <t>Reserved: This byte MUST be set to zero on transmit and ignored on
      receive.</t>

      <t>Sequence Number: The sequence number for this packet. Implementation
      may use sequence numbers (bfd.XmitAuthSeq) as defined in <xref
      target="RFC5880">BFD</xref>, or secure sequence numbers as defined in
      <xref target="I-D.ietf-bfd-secure-sequence-numbers">Secure BFD Sequence
      Numbers </xref>.</t>

      <t>The NULL Auth Type must be used for all packets that are not
      authenticated. This protects against replay-attacks by allowing the
      session to maintain an incrementing sequence number for all packets
      (authenticated and un-authenticated).</t>

      <t>In the future, if a new scheme is adopted for changing the sequence
      number, this method can adopt the new scheme without any impact.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests an update to the registry titled "BFD
      Authentication Types". IANA is requested to assign a new BFD Auth Type
      for "NULL" (see Section 3).</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The approach described in this document enhances the ability to
      authenticate a BFD session by taking away the onerous requirement that
      every BFD control packet be authenticated. By authenticating packets
      that affect the state of the session, the security of the BFD session is
      maintained. In this mode, packets that are a significant change but are
      not authenticated, are dropped by the system. Therefore, a malicious
      user that tries to inject a non-authenticated packet, e.g. with a Down
      state to take a session down will fail. That combined with the proposal
      of using sequence number defined in <xref
      target="I-D.ietf-bfd-secure-sequence-numbers">Secure BFD Sequence
      Numbers</xref> further enhances the security of BFD sessions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>

      <?rfc include='reference.RFC.5880.xml'?>

      <?rfc include='reference.RFC.8174.xml'?>

      <?rfc include='reference.I-D.ietf-bfd-secure-sequence-numbers.xml'?>
    </references>

    <references title="Informative References">
      <reference anchor="SHA-1-attack1">
        <front>
          <title>Finding Collisions in the Full SHA-1</title>

          <author initials="X." surname="Wang">
            <organization/>
          </author>

          <author initials="Y." surname="Yin">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <author initials="H." surname="Yu">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <date year="2005"/>
        </front>
      </reference>

      <reference anchor="SHA-1-attack2">
        <front>
          <title>New Collision Search for SHA-1</title>

          <author initials="X." surname="Wang">
            <organization/>
          </author>

          <author initials="A." surname="Yao">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <author initials="F." surname="Yao">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <date year="2005"/>
        </front>
      </reference>

      <?rfc include='reference.RFC.1321.xml'?>

      <?rfc include='reference.RFC.6151.xml'?>

      <?rfc include='reference.RFC.6194.xml'?>
    </references>
  </back>
</rfc>
