One document matched: draft-mahesh-karp-rsvp-te-analysis-01.xml

<?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-rsvp-te-analysis-01.txt"
     ipr="trust200902">
  <front>
    <title abbrev="RSVP-TE Analysis">Analysis of RSVP-TE Security According to
    KARP Design Guide</title>

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

      <address>
        <postal>
          <street>1741 Technology Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95110</code>

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

        <phone>+1 (408) 436-3313</phone>

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

    <author fullname="Dacheng Zhang" initials="D." surname="Zhang">
      <organization>Huawei Technologies co., LTD.</organization>

      <address>
        <postal>
          <street></street>

          <city>Beijing</city>

          <region></region>

          <code></code>

          <country>China</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>zhangdacheng@huawei.com</email>

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

    <date day="20" month="May" year="2013" />

    <area>Network</area>

    <workgroup>Routing Working Group</workgroup>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document analyzes Resource reSerVation Protocol-Traffic
      Engineering (RSVP-TE) 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 RSVP-TE 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="I-D.ietf-karp-routing-tcp-analysis">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="RFC2205">Resource reSerVation Protocol (RSVP)</xref> is
      a resource reservation setup protocol designed for an integrated
      services. <xref target="RFC4230">RSVP Security Properties</xref>
      indicates the unfeasibility of using IPSec to secure RSVP signaling
      messages. <xref target="RFC2747">RSVP Cryptographic
      Authentication</xref> describes the format and use of RSVP's INTEGRITY
      objects to provide hop-by-hop integrity and authentication of RSVP
      messages. <xref target="RFC3209">RSVP-TE: Extensions to RSVP for LSP
      Tunnels</xref> is an extension of the RSVP protocol to establish
      Multi-Protocol Label Switching (MPLS) Label Switch Paths (LSPs). RSVP-TE
      signaling messages are used to establish both intra- and inter-domain TE
      LSPs. The security mechanisms for RSVP, <xref target="RFC2747">RSVP
      Cryptographic Authentication</xref> can be used by RSVP-TE to provide
      the security protection for the RSVP-TE message transportation.
      Therefore, the rest of the document will focus on the current state of
      security efforts for RSVP and assume that will apply to RSVP-TE
      also.</t>

      <t>Section 2 looks at the current security state of RSVP-TE. Section 3
      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>BGP - Border Gateway Protocol</t>

        <t>DoS - Denial of Service</t>

        <t>KARP - Key and Authentication for Routing Protocols</t>

        <t>KDF - Key Derivation Function</t>

        <t>KEK - Key Encrypting Key</t>

        <t>KMP - Key Management Protocol</t>

        <t>LDP - Label Distribution Protocol</t>

        <t>LSP - Label Switch Path</t>

        <t>MAC - Message Authentication Code</t>

        <t>MKT - Master Key Tuple</t>

        <t>MPLS - Multi Protocol Label Switching</t>

        <t>MSDP - Multicast Source Distribution Protocol</t>

        <t>MD5 - Message Digest algorithm 5</t>

        <t>PCEP - Path Computation Element Protocol</t>

        <t>RSVP - Resource reSerVation Protocol</t>

        <t>TCP - Transmission Control Protocol</t>

        <t>UDP - User Datagram Protocol</t>
      </section>
    </section>

    <section title="Current Assessment of RSVP-TE">
      <t>This section looks at RSVP-TE and the underlying transport protocol
      and key mechanisms built for the protocol.</t>

      <section title="Transport Layer">
        <t>RSVP operates on top of IPv4 or IPv6, occupying the place of a
        transport protocol in the protocol stack. However, RSVP does not
        transport application data but is rather an Internet control protocol,
        like ICMP, IGMP, or routing protocols.</t>

        <section title="UDP Encapsulation">
          <t>An RSVP implementation generally requires the ability to perform
          "raw" network I/O. However, some systems may not support raw network
          I/O. To use RSVP, such hosts must encapsulate RSVP messages in
          UDP.</t>
        </section>
      </section>

      <section title="Keying Mechanism">
        <t>Section 7 of RSVP Cryptographic Authentication discusses the
        possibility of using Kerberos to generate and distribute RSVP
        authentication keys. However, the design of Automated Key Management
        (AKM) mechanism for RSVP is still incomplete. There is no other AKM
        solution proposed at this time. If anything, manual key management is
        used.</t>

        <t>The protocol states that manual keying should be supported and
        states the need for a key management protocol to distribute keys. It
        even states that the Key Identifier be the hook between RSVP and the
        key management protocol. But it deliberately excludes defining a
        integrated key management protocol technique in the document. It does
        define a key lifetime that should be recorded for all systems although
        how they are presented e.g. using the start time and the end time of
        the key life period, is not specified. It even advises that the keys
        should be changed on a regular basis and that multiple keys should be
        used to transition from one key to another.</t>
      </section>

      <section title="Message Integrity and Node Authentication">
        <t>RSVP-TE makes use of <xref target="RFC2747">RSVP Cryptographic
        Authentication</xref>. Note that there is currently no RSVP-TE
        specific security mechanism. It is required that RSVP-TE headers and
        payload be authenticated, but there is no requirement that RSVP-TE
        headers be encrypted.</t>

        <t><xref target="RFC2747">RSVP Cryptographic Authentication</xref>
        defines the use HMAC-MD5 for both message integrity and node
        authentication. The length of the keyed digests is 128 bits. In these
        cases RSVP checksum can be disabled in lieu of message digest. In
        addition, no algorithm agility is supported.</t>
      </section>

      <section title="Replay Protection">
        <t>RSVP uses 64 bit monotonically increasing sequence numbers to
        prevent against replay attacks. The sequence number space is large
        enough to guarantee that a sequence number will never reach its
        maximum and roll back within a reasonable long period.</t>

        <t>The solution provides three approaches to generate unique
        monotonically increasing sequence numbers across a failure or a
        restart. The solutions include:</t>

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

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

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

      <section title="Out of Order Protection">
        <t>To address the issue of out-of-order message delivery, the solution
        proposed in <xref target="RFC2747">RSVP Cryptographic
        Authentication</xref> allows administrators to specify a sequence
        number window corresponding to the worst case reordering behavior.
        Instead of requiring the sequence number of an incoming packet to be
        strictly larger than the ones previously received, a packet will be
        accepted if its sequence number is within the window. </t>
      </section>

      <section title="Denial of Service Attack Protection">
        <t>RSVP does not explicitly mention Denial of Service (DoS) attacks
        and how to prevent against it. However, a RSVP-TE node does know the
        peers that it should be communicating with and can therefore accept
        packets from known hosts only. This feature can largely mitigate the
        security risks caused by DoS attacks.</t>
      </section>
    </section>

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

      <t>In <xref target="RFC2747">RSVP Cryptographic Authentication</xref>,
      only the usage of MD5 to generate digests for RSVP-TE messages is
      defined. In order to fulfill the requirement of supporting strong
      algorithms and cryptographic algorithm agility, at least the support of
      SHA-2 and the ability to indicate additional algorithms needs to be
      provided..</t>

      <t>In addition, in <xref target="RFC2747">RSVP Cryptographic
      Authentication</xref>, three approaches to generating unique
      monotonically increasing sequence numbers across a failure and restart
      are introduced, but no approach is mandated. However, as mentioned
      above, when using Network Recovered Clocks into the generation of
      sequence numbers, the capability of RSVP-TE in tolerating
      inter-connection replay attacks will largely rely on the security of
      network timing protocols. Therefore, in future this approach should not
      be recommended.</t>
    </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 RSVP-TE.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Sean Turner for his review and
      comments on the draft.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

      <?rfc include="reference.RFC.4271"
?>

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

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

      <?rfc include="reference.RFC.5036"
?>

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-karp-routing-tcp-analysis'?>
    </references>
  </back>
</rfc>