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

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="info" docName="draft-mahesh-karp-rsvp-te-analysis-00.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="16" month="December" year="2012" />

    <area>Network</area>

    <workgroup>Routing Working Group</workgroup>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document analyzes RSVP-TE according to guidelines set forth in
      section 4.2 of <xref target="RFC6518">KARP Design Guidelines</xref>.</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 suggests steps to tighten the infrastructure
      against the attack.</t>

      <t>This document performs the 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. The OPSEC working group put
      together <xref target="RFC6039">Issues with existing Cryptographic
      Protection Methods for Routing Protocols </xref> an analysis of
      cryptographic issues with routing protocols and <xref
      target="draft-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>

      <t>Section 2 looks at the current security state of RSVP-TE. Section 3
      does a 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 Security State of RSVP-TE">
      <t>This section looks at RSVP-TE and the underlying transport protocol
      and key mechanisms built for the protocol.</t>

      <t>RSVP-TE is an extension of the RSVP protocol for traffic engineering.
      It supports the reservation of resources across IP networks and is used
      for establishing Multi Protocol Label Switching (MPLS) Label Switch
      Paths (LSPs). RSVP-TE signaling is used to establish both intra- and
      inter-domain TE LSPs. It is <xref target="RFC2747">RSVP Cryptographic
      Authentication</xref> that describes the format and use of RSVP's
      INTEGRITY objects to provide hop-by-hop integrity and authentication of
      RSVP messages. RSVP-TE which uses some of the same formats therefore can
      make use of some of the same authentication mechanisms. The rest of the
      document will therefore focus on current state of security for RSVP.
      Currently, there is no security approach specified for RSVP-TE
      particularly. However, the security mechanisms for RSVP <xref
      target="RFC2747">RSVP Cryptographic Authentication</xref> can be taken
      advantage of to provide the security protection for the RSVP-TE message
      transportation.</t>

      <t>There is a requirement that RSVP-TE headers and payload be
      authenticated. There is no requirement that they be encrypted and that
      work is outside the scope of KARP WG. <xref target="RFC2747">RSVP
      Cryptographic Authentication</xref> outlines the use HMAC-MD5. When
      using HMAC-MD5, the length of the keyed digests is 128 bits. In these
      cases RSVP checksum can be disabled in lieu of message digest.</t>

      <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>To address the issue of out-of-order message delivery, the solution
      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. 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>

      <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 draft. However, it does define
      a key lifetime that should be recorded for all systems using values such
      as KeyStartValid and KeyEndValid. 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>

      <t>RSVP does not explicitly mention Denial of Service (DoS) attacks and
      how to prevent against it. However, RSVP-TE does know the peers that it
      should be communicating with and can therefore accept packets from known
      hosts only.</t>
    </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
      mentioned. In order to fulfill the requirement of supporting strong
      algorithms, at least the support of SHA-2 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>None</t>
    </section>

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

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

      <?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.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.I-D.draft-ietf-karp-threats-reqs-06'?>

      <reference anchor="draft-ietf-karp-routing-tcp-analysis">
        <front>
          <title>Analysis of BGP, LDP, PCEP, MSDP Issues According to KARP
          Design Guide</title>

          <author fullname="Mahesh" initials="MJ" surname="Jethanandani">
            <organization>j</organization>
          </author>

          <date day="30" month="July" year="2012" />
        </front>
      </reference>
    </references>
  </back>
</rfc>