<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-mahesh-karp-lmp-analysis-01.txt"
     ipr="trust200902">
  <front>
    <title abbrev="RSVP-TE Analysis">Analysis of LMP Security According to
    KARP Design Guide</title>

    <author fullname="Mahesh Jethanandani" initials="M."
            surname="Jethanandani">
      <organization>Ciena Corporation</organization>

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

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <phone>+1 (408) 904-2160</phone>

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

    <date day="11" month="February" year="2014" />

    <area>Network</area>

    <workgroup>Routing Working Group</workgroup>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document analyzes Link Management Protocol (LMP) according to
      guidelines set forth in section 4.2 of KARP Design Guidelines (RFC
      6518).</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>In March 2006, the Internet Architecture Board (IAB) described an
      attack on core routing infrastructure as an ideal attack that would
      inflict the greatest amount of damage, in their <xref
      target="RFC4948">Report from the IAB workshop on Unwanted Traffic March
      9-10, 2006</xref>, and suggested steps to tighten the infrastructure
      against the attack. Four main steps were identified for that
      tightening:</t>

      <t><list style="numbers">
          <t>Create secure mechanisms and practices for operating routers.</t>

          <t>Clean up the Internet Routing Registry (IRR) repository, and
          securing both the database and the access, so that it can be used
          for routing verifications.</t>

          <t>Create specifications for cryptographic validation of routing
          message content.</t>

          <t>Secure the routing protocols' packets on the wire.</t>
        </list></t>

      <t>In order to secure the routing protocols this document performs an
      initial analysis of the current state of LMP according to the
      requirements of <xref target="RFC6518">KARP Design Guidelines </xref>.
      This draft builds on several previous analysis efforts into routing
      security:</t>

      <t><list style="symbols">
          <t><xref target="RFC6039">Issues with existing Cryptographic
          Protection Methods for Routing Protocols</xref> an analysis of
          cryptographic issues with routing protocols.</t>

          <t><xref target="RFC6863">Analysis of OSPF Security According to
          KARP Design Guide</xref>.</t>

          <t><xref target="RFC6952">Analysis of BGP, LDP, PCEP, and MSDP
          Issues According to KARP Design Guide</xref> which is a analysis of
          the four routing protocols.</t>
        </list></t>

      <t><xref target="RFC4204">Link Management Protocol (LMP)</xref> is used
      to manage Traffic Engineering (TE) links. According to the document, LMP
      can be subject to a number of attacks. Some examples include:</t>

      <t><list style="symbols">
          <t>an adversary may spoof control packets</t>

          <t>an adversary may modify the control packet in transit</t>

          <t>an adversary may replay control packets</t>

          <t>an adversary may study a number of control packets and try to
          break the key using cryptographic tools.</t>
        </list></t>

      <t>Section 2 looks at the current security state of LMP. Section 3
      suggest an optimal security state and section 4 does an analysis of the
      gap between the existing and the optimal security state of the protocol
      and suggest some areas where we need to improve.</t>

      <section title="Abbreviations">
        <t>LMP - Link Management Protocol</t>

        <t>TE - Traffic Engineering</t>
      </section>
    </section>

    <section title="Current Assessment of LMP">
      <t>This section looks at LMP procedure, the underlying transport layer
      and security assessment associated with LMP.</t>

      <section title="LMP Procedure">
        <t>The two core procedures of LMP procedure are control channel
        management and link property correlation. Control channel management
        is used to establish and maintain control channels between adjacent
        nodes. This is done using a Config message exchange and a fast
        keep-alive mechanism between the nodes. Link property correlation is
        used to synchronize the TE link properties and verify the TE link
        configuration.</t>

        <t>Two additional procedures include link connectivity verification
        and fault management. Link connectivity verification is used for data
        plane discovery, Interface_Id exchange, and physical connectivity
        verification. This is done by sending Test messages over the data
        channel and the TestStatus messages coming back over the control
        plane. The LMP link connectivity verification procedure is coordinated
        using the BeginVerify message exchanged over the control channel.</t>

        <t>The LMP fault management procedure is based on a ChannelStatus
        message exchange. The ChannelStatus message is sent unsolicited and is
        used to notify an LMP neighbor about the status of one or more data
        channels. ChannelStatusAck is used to acknowledge receipt of the
        ChannelStatus message. Similarly, a ChannelStatusResponse message is
        used to acknowledge receipt of a ChannelStatusRequest message.</t>
      </section>

      <section title="Transport Layer">
        <t>Except for Test messages, all LMP packets use UDP to communicate
        with its piers over a LMP port number. Multiple "LMP adjacencies" may
        be formed and be active between two nodes. LMP messages are
        transmitted reliably using Message_Ids and retransmissions.</t>

        <t>Unlike TCP which can use <xref target="RFC5925">TCP-AO</xref> for
        message authentication, UDP does not have any of authenticating
        packets.</t>
      </section>

      <section title="Message Integrity and Node Authentication">
        <t><xref target="RFC4204">LMP</xref> recommends the use of IPSec for
        authentication. That document also states that there is currently no
        requirement that LMP headers or payload be encrypted. It also states
        that LMP endpoint identity does not need to be protected.</t>

        <t>To authenticate LMP, the document further states that manual keying
        mode be supported. However, it notes that manual keying cannot
        effectively support replay protection and automatic re-keying. It
        therefore recommends that manual keying should only be used for
        diagnostic purposes and only use automatic re-keying for replay
        protection and automatic re-keying.</t>
      </section>

      <section title="Replay Attack">
        <t>MESSAGE_ID and MESSAGE_ID_ACK objects are included in the LMP
        messages to support reliable message delivery. The Message_Id field of
        the MESSAGE_ID object contains a generator selected value. This value
        is supposed to be monotonically increasing. A value is considered to
        be used when it has been sent in an LMP message with the same CC_Id or
        LMP adjacency. The Message_Id field of the MESSAGE_ID_ACK contains the
        Message_Id field of the message being acknowledged.</t>

        <t>Unacknowledged messages sent with the MESSAGE_ID object are to be
        retransmitted until the message is acknowledged or until a retry limit
        is reached. The Message_Id field is 32 bit wide and may wrap.</t>

        <t>The 32-bit Message_Id number space is not large enough to guarantee
        that the Message_Id number will not wrap around within a reasonable
        long period. Therefore, the system is susceptible to a replay
        attack.</t>

        <t>In addition, LMP does not provide for a generation of a unique
        monotonically increasing sequence numbers across a failure or a
        restart.</t>
      </section>

      <section title="Out-of-order Protection">
        <t>LMP states that nodes processing incoming messages are supposed to
        check to see if the newly received message is out of order messages,
        and if so, they are to be ignored and dropped silently.</t>

        <t>Specifically, if the message is a Config message, and the
        Message_Id value is less than the largest Message_Id value previously
        received from the sender for the CC_Id, then the message is supposed
        to be treated as being out-of-order. If the message is a LinkSummary
        message and the Message_Id value is less than the largest Message_Id
        value previously received from the sender of the TE link, then the
        message is supposed to be treated as being out-of-order. Similarly, if
        the message is a ChannelStatus message and the Message_Id value is
        less than the largest Message_id value previously received from he
        sender of the specific TE link, then the receiver is supposed to check
        for the Message_Id value previously received from the state of each
        data channel included in the ChannelStatus message. If the Message_Id
        value associated with at least one of the data channels included in
        the message, the message is not supposed to be treated as
        out-of-order. All other messages are not supposed to be treated as
        out-of-order.</t>
      </section>
    </section>

    <section title="Security Requirements for LMP">
      <t><xref target="RFC4204">LMP</xref> states that the following
      requirements should be applied to secure the protocol.</t>

      <t><list style="symbols">
          <t>LMP security must be able to provide authentication, integrity
          and replay protection.</t>

          <t>Confidentiality is not needed for LMP traffic.</t>

          <t>The protection of identity of the LMP end-points is not commonly
          required.</t>

          <t>The security mechanism should provide for a well defined key
          management scheme. The key management scheme should be scalable and
          should provide for automatic key rollover.</t>

          <t>The algorithm used for authentication must be cryptographically
          sound and it should provide for algorithm agility.</t>
        </list></t>
    </section>

    <section title="Gap Analysis for LMP">
      <t>This section outlines the differences between the current state of
      LMP and the desired state as outlined in sections 4.1 and 4.2 of <xref
      target="RFC6518">KARP Design Guidelines </xref>.</t>

      <section title="Replay Protection">
        <t>As outlined above, LMP protocol is subject to replay attacks.
        Solutions to replay protection include:</t>

        <t><list style="numbers">
            <t>Maintaining Message_Id numbers in stable memory</t>

            <t>Introducing the data from a local time clock into the
            generation of Message_Id numbers after a restart</t>

            <t>Introducing the timing information from a Network Recovered
            Clock into the generation of Message_Id numbers after a
            restart.</t>
          </list>In addition, a handshake is defined for a receiver to get the
        latest value of a Message_Id number. Therefore, this solution is
        effective in addressing the issues caused by the rollback of
        Message_Id numbers across a system restart or failure. However, when a
        router uses the approach to generating Message_Id numbers with the
        time information from NTP, an attacker may try to deceive the router
        to generate a Message_Id number which is less than the Message_Id
        numbers it used to have, by sending replayed or foiled NTP
        information.</t>
      </section>
    </section>

    <section title="IANA Requirements">
      <t>This document makes no IANA requests, and the RFC Editor may consider
      deleting this section on publication of this document as a RFC.</t>
    </section>

    <section title="Security Consideration">
      <t>This document is all about security considerations for LMP.</t>
    </section>

    <section title="Acknowledgements">
      <t></t>
    </section>
  </middle>

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

      <?rfc include='reference.RFC.6518'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4948'?>

      <?rfc include='reference.RFC.5925'?>

      <?rfc include='reference.RFC.6039'?>

      <?rfc include='reference.RFC.6863'?>

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