<?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="info" docName="draft-ietf-karp-ospf-analysis-06.txt"
     ipr="trust200902">
  <front>
    <title abbrev="OSPF Analysis">Analysis of OSPF Security According to KARP
    Design Guide</title>

    <author fullname="Sam Hartman" initials="S." surname="Hartman">
      <organization>Painless Security</organization>

      <address>
        <email>hartmans-ietf@mit.edu</email>

        <uri>http://www.painless-security.com/</uri>
      </address>
    </author>

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

      <address>
        <postal>
          <street>Huawei Building No.3 Xinxi Rd., Shang-Di Information
          Industrial Base Hai-Dian District, Beijing</street>

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

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

    <date />

    <area/>

    <workgroup>KARP</workgroup>

    <keyword>Internet-Draft</keyword>

    <keyword>Draft</keyword>

    <abstract>
      <t>This document analyzes OSPFv2 and OSPFv3 according to the guidelines
      set forth in section 4.2 of RFC6518.
Key components of solutions to gaps identified in this draft are already underway.</t>
    </abstract>

    <note 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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document analyzes  the current state of
      OSPFv2 and OSPFv3 according to the requirements of <xref
      target="RFC6518"></xref>. This draft builds on
      several previous analysis efforts into routing security. The OPSEC
      working group put together <xref target="RFC6039"></xref> an analysis of
      cryptographic issues with routing protocols. Earlier, the RPSEC working
      group put together <xref target="I-D.ietf-rpsec-ospf-vuln"></xref> a
      detailed analysis of OSPF vulnerabilities. Solution work  to address gaps identified in this analysis is underway <xref target="I-D.ietf-ospf-security-extension-manual-keying"></xref> <xref target="RFC6506"></xref></t>


      <t>OSPF meets many of the requirements expected from a manually keyed
      routing protocol. Integrity protection is provided with modern
      cryptographic algorithms. Algorithm agility is provided: the algorithm
      can be changed as part of re-keying an interface or peer.
      Intra-connection re-keying is provided by the specifications, although
      apparently some implementations have trouble with this in practice.
      OSPFv2 security does not interfere with prioritization of packets.</t>

      <t>However, some gaps remain between the current state and the
      requirements for manually keyed routing security expressed in <xref
      target="I-D.ietf-karp-threats-reqs"></xref>. This
      document explores these gaps and proposes directions for addressing the
      gaps.</t>

      <section title="Requirements to Meet">
        <t>There are a number of requirements described in section 3 of <xref
        target="I-D.ietf-karp-threats-reqs"></xref> that OSPF does not
        currently meet. The gaps are as follows:<list style="symbols">
            <t>Secure Simple PSKs: Today, OSPF directly uses the key as
            specified. Related key attacks such as those described in section
            4.1 of <xref target="I-D.ietf-karp-ops-model"></xref> are
            possible.<vspace/></t>

            <t>Replay Protection: The requirements document addresses requirements for both inter-connection replay protection and intra-connection replay protection. OSPFv3 has no replay protection at all.
            OSPFv2 has most of the mechanisms necessary for intra-connection
            replay protection. Unfortunately, OSPFv2 does not securely
            identify the neighbor with whom replay protection state is
            associated in all cases. This weakness can be used to create
            significant denial-of- service issues using intra-connection
            replays. OSPFv2 has no inter-connection replay protection; this
            creates significant denial-of-service opportunities.<vspace/></t>

            <t>Packet Prioritization: OSPFv3 uses IPsec <xref target="RFC4301" />to process packets.
            This complicates implementations that wish to process some packets
            such as hellos and acknowledgements above others. In addition, if
            IPsec replay mechanisms were used, packets would need to be
            processed at least by IPsec even if they were low priority.</t>

            <t>Neighbor Identification: In some cases, OSPF identifies a
            neighbor based on the IP address. This is never protected with
            OSPFv2 and is not typically protected with OSPFv3.</t>
          </list></t>

        <t>The remainder of this document explains the details of how these
        requirements fail to be met and proposes mechanisms for addressing
        them.</t>
      </section>

      <section title="Requirements notation">
        <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 [RFC2119].</t>
      </section>
    </section>

    <section title="Current State">
      <t>This section describes the security mechanisms built into OSPFv2 and
      OSPFv3. There are two goals to this section. First, this section gives a
      brief explanation of the OSPF security mechanisms to those familiar with
      connectionless integrity mechanisms but not with OSPF. Second, this
      section explains the background necessary to understand how OSPF fails
      to meet some of the requirements proposed for routing security.</t>

      <section title="OSPFv2">
        <t>Appendix D of <xref target="RFC2328"/> describes the basic
        procedure for cryptographic authentication in OSPFv2. An
        authentication data field in the OSPF packet header contains a key ID,
        the length of the authentication data and a sequence number. A message
        authentication code (MAC) is appended to the OSPF packet. This code
        protects all fields of the packet including the sequence number but
        not the IP header.</t>

        <t>RFC 2328 defined the use of a keyed-MD5 MAC. While MD5 has not been
        broken as a MAC, it is not the algorithm of choice for new MACs.</t>

        <t>However, RFC 5709 <xref target="RFC5709"/> adds support for the SHA
        <xref target="FIPS180"/> family of hashes to OSPFv2. The cryptographic
        authentication described in RFC 5709 meets modern standards for
        per-packet integrity protection. Thus, OSPFv2 meets the requirement
        for strong algorithms. Since multiple algorithms are defined and a new
        algorithm can be selected with each key, OSPFv2 meets the requirement
        for algorithm agility. In order to provide cryptographic algorithms
        believed to have a relatively long useful life, RFC 5709 mandates
        support for SHA-2 rather than SHA-1.</t>

        <t>These security services provide integrity protection on each
        packet. In addition, limited replay detection is provided. The
        sequence number is non-decreasing. So, once a router has increased its
        sequence number, an attacker cannot replay an old packet.
        Unfortunately, sequence numbers are not required to increase for each
        packet. For instance, because existing OSPF security solutions do not
        specify how to set the sequence number, it is possible that some
        implementations use, e.g., "seconds since reboot" as their sequence
        numbers. The sequence numbers are thus only increased by every second, permitting an opportunity for intra-connection replay.
        Also, no mechanism is provided to deal with the loss of anti-replay
        state; if sequence numbers are reused when a router reboots, then
        inter-connection replays are straight forward. In <xref
        target="I-D.ietf-ospf-security-extension-manual-keying"/>, the OSPFv2
        sequence number is expanded to 64-bits with the least significant
        32-bit value containing a strictly increasing sequence number and the
        most significant 32-bit value containing the boot count. The boot
        count is retained in non-volatile storage for the deployment life of a
        OSPF router. Therefore, the sequence number will never decrease even
        after a cold reboot.</t>

        <t>Also, because the IP header is not protected, the sequence number
        may not be associated with the right neighbor; this opens up
        opportunities for outsiders to perform replay attacks. See Section 3
        for analysis of these attacks. In <xref
        target="I-D.ietf-ospf-security-extension-manual-keying"/>, this issue
        is addressed by changing the definition of Apad from a constant
        defined in <xref target="RFC5709"/> to the source address from the IP
        header of the OSPFv2 protocol packet. In this way, the source address
        from the IP header is incorporated in the cryptographic authentication
        computation, and any change of the IP source address will be
        detected.</t>

        <t>The mechanism provides good support for key rollover. There is a
        key ID; in addition mechanisms are described for managing key
        lifetimes and starting the use of a new key in an orderly manner.
        Performing orderly key rollover requires that implementations support
        accepting a new key for received packets before using that key to
        generate packets. Section D.3 of RFC 2328 requires this support in the
        form of four configurable lifetimes for each key: two lifetimes
        control the beginning and ending period for acceptance while two
        lifetimes control the beginning and ending period for generation. This
        provides a superset of the functionality in the key table <xref
        target="I-D.ietf-karp-crypto-key-table"/> regarding lifetime.</t>

	<t>       The OSPFv2 replay mechanism does not handle prioritized transmission of OSPF Hello and Link State Acknowledgement packets as recommended in <xref target="RFC4222"></xref>. When OSPF packets are transmitted with varied prioritization, they can arrive out-of-order resulting in packets with lower prioritization being discarded. </t>
      </section>
      <section title="OSPFv3">
        <t>RFC 4552  describes how the
        IPsec authentication header and encapsulating security payload mechanism can
        be used to protect OSPFv3 packets. This mechanism provides per-packet
        integrity and optional confidentiality using a wide variety of
        cryptographic algorithms. Because OSPF uses multicast traffic, only
        manual key management is supported. This mechanism meets requirements
        related to algorithm selection and agility.</t>

        <t>The Security Parameter Index (SPI) <xref target="RFC4301" /> provides an identifier for the
        security association. This along with other IPsec facilities provides
        a mechanism for moving from one key to another, meeting the key
        rollover requirements.</t>

        <t>Because manual keying is used, no replay protection is provided for
        OSPFv3. Thus the intra-connection and inter-connection replay
        requirements are not met.</t>

        <t>There is another serious problem with the OSPFv3 security: rather
        than being integrated into OSPF, it is based on IPsec. In practice,
        this has lead to deployment problems.</t>

        <t>OSPF implementations generally prioritize packets in order to
        minimize disruption when router resources such as CPU or memory
        experience contention. When IPsec is used with OSPFv3, the offset of
        the packet type, which is used to prioritize packets, depends on what
        integrity transform is used. For this reason, prioritizing packets may
        be more complex for OSPFv3. One approach is to establish per-SPI
        filters to find the packet type and act accordingly.</t>
      </section>
    </section>

    <section title="Impacts of OSPF Replays">
      <t>As discussed, neither version of OSPF meets the requirements of
      inter-connection or intra-connection replay protection. In order to mount a replay, an attacker needs some mechanism to inject a packet; physical security can limit a particular deployment's vulnerability to replay attacks. This section
      discusses the impacts of OSPF replays.</t>

      <t>In OSPFv2, two facilities limit the scope of replay attacks. First,
      when cryptographic authentication is used, each packet includes a
      sequence number that is non-decreasing. In the current specifications,
      the sequence number is remembered as part of an adjacency: if an
      attacker can cause an adjacency to go down, then replay state is lost.
      Database Description packets also include a per-LSA sequence number that
      is part of the information that is flooded. Even if a packet is
      replayed, the per-LSA sequence number will prevent an old LSA from being
      installed. Unlike the per-packet sequence number, the per-LSA sequence
      number must increase when an LSA is changed. As a result, replays cannot
      be used to install old routing information.</t>

      <t>While the LSA sequence number provides some defense, the       RPSEC analysis <xref target="I-D.ietf-rpsec-ospf-vuln"></xref> describes
      a number of attacks that are possible because of per-packet replays. The

      most serious appear to be attacks against Hello packets, which may cause
      an adjacency to fail. Other attacks may cause excessive flooding or
      excessive use of CPU.</t>

      <t>Another serious attack concerns Database Description packets. In
      addition to the per-packet sequence number that is part of cryptographic
      authentication for OSPFv2 and the per-LSA sequence numbers, Database
      Description packets also include a Database Description sequence number.
      If a Database Description packet with the incorrect sequence number is
      received, then the database exchange process will be restarted.</t>

      <t>The per-packet OSPFv2 sequence number can be used to reduce the
      window in which a replay is valid. A receiver will harmlessly reject a
      packet whose per-packet sequence number is older than the one most
      recently received from a neighbor. Replaying the most recent packet from
      a neighbor does not appear to create problems. So, if the per- packet
      sequence number is incremented on every packet sent, then replay attacks
      should not disrupt OSPFv2. Unfortunately, OSPFv2 does not have a
      procedure for dealing with sequence numbers reaching the maximum value. It
      may be possible to figure out a set of rules sufficient to disrupt the
      damage of packet replays while minimizing the use of the sequence number
      space.</t>

      <t>As mentioned previously, when an adjacency is dropped, replay state
      is lost. So, after rebooting or when all adjacencies are lost, a router
      may allow its sequence number to decrease. An attacker can cause
      significant damage by replaying a packet captured before the sequence
      number decrease at a time after the sequence number decrease. If this
      happens, then the replayed packet will be accepted and the sequence
      number will be updated. However, the legitimate sender will be using a
      lower sequence number, so legitimate packets will be rejected. A similar
      attack is possible in cases where OSPF identifies a neighbor based on
      source address. An attacker can change the source address of a captured
      packet and replay it. If the attacker causes a replay from a neighbor
      with a high sequence number to appear to be from a low sequence number
      neighbor, then connectivity with that neighbor will be disrupted until
      the adjacency fails.</t>

      <t>OSPFv3 lacks the per-packet sequence number but has the per-LSA
      sequence number. As such, OSPFv3 has no defense against denial of
      service attacks that exploit replay.</t>
    </section>

    <section title="Gap Analysis and Specific Requirements">
      <t>The design guide requires each design team to enumerate a set of
      requirements for the routing protocol. The only concerns identified with
      OSPF are areas where it fails to meet general requirements outlined in
      the threats and requirements document. This section explains how some of
      these general requirements map specifically onto the OSPF protocol and
      enumerates the specific gaps that need to be addressed.</t>

      <t>There is a general requirement for inter-connection replay
      protection. In the context of OSPF, this means that if an adjacency goes
      down between two neighbors and later is re-established, replaying
      packets from before the adjacency went down cannot disrupt the
      adjacency. In the context of OSPF, intra-connection replay protection
      means that replaying a packet cannot prevent an adjacency from forming
      or disrupt an adjacency. Meeting the requirements for intra-connection
      and inter-connection replay protection is a significant gap between the
      optimal state and where OSPF is today.</t>

      <t>Since OSPF uses fields in the IP header, the general requirement to
      protect the IP header and handle neighbor identification applies. This
      is another gap that needs to be addressed. Because the replay protection
      will depend on neighbor identification, the replay protection cannot be
      adequately addressed without handling this issue as well.</t>

      <t>In order to encourage deployment of OSPFv3 security, an
      authentication option is required that does not have the deployment
      challenges of IPsec.</t>

      <t>In order to support the requirement for simple preshared keys, OSPF
      needs to make sure that when the same key is used for two different
      purposes, no problems result.</t>

      <t>In order to support packet prioritization, it is desirable for the information needed to
      prioritize OSPF packets (the packet type) to  be at a constant location
      in the packet.</t>

      <t/>
    </section>

    <section title="Solution Work">
      <t>A security solution will be developed for OSPFv2 and OSPFv3 based on
      the OSPFv2 cryptographic authentication option. This solution will have
      the following improvements over the existing OSPFv2 option:<list
          style="empty">
          <t>Address most inter-connection replay attacks by splitting the
          sequence number and requiring preservation of state so that the
          sequence number increases on every packet.<vspace/></t>

          <t>Add a form of simple key derivation so that if the same preshared
          key is used for OSPF and other purposes, cross-protocol attacks do
          not result<vspace/></t>

          <t>Support OSPFv3 authentication without use of IPsec<vspace/></t>

          <t>Specify processing rules sufficient to permit replay detection
          and packet prioritization<vspace/></t>

          <t>Emphasize requirements already present in the OSPF specification
          sufficient to permit key migration without disrupting
          adjacencies<vspace/></t>

          <t>Specify the proper use of the key table for OSPF<vspace/></t>

          <t>Protect the source IP address<vspace/></t>

          <t>Require that sequence numbers be incremented on each packet</t>
        </list></t>

      <t>The key components of this solution work are already underway. OSPFv3
      now supports an authentication option <xref target="RFC6506"/> that
      meets the requirements of this section, except that it does not describe
      how the key tables are used for OSPF. OSPFv2 is being enhanced <xref
      target="I-D.ietf-ospf-security-extension-manual-keying"/> to protect the
      source address, provide inter-connection replay and describe how to use
      the key table.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This memo discusses and compiles vulnerabilities in the existing OSPF
      cryptographic handling.</t>

      <t>In analyzing proposed improvements to OSPF per-packet security, it is
      desirable to consider how these improvements interact with potential
      improvements in overall routing security. For example, the impact of
      replay attacks currently depends on the LSA sequence number mechanism.
      If cryptographic protections against insider attackers are considered by
      future work, then that work will need to provide a solution that meets
      the needs of the per-packet replay defense as well as protection of
      routing data from insider attack. An experimental solution is discussed in  <xref
      target="RFC2154"></xref> that explores 
      end-to-end protection of routing data in OSPF. It may be beneficial to
      consider how improvements to the per-packet protections would interact
      with such a mechanism to future-proof these mechanisms.</t>

      <t>Implementations have a number of options in minimizing the potential
      denial of service impact of OSPF cryptographic authentication. The
      Generalized TTL Security Mechanism (GTSM) <xref target="RFC5082"/> might
      be appropriate for OSPF packets other than those traversing virtual
      links. Using this mechanism requires support of the sender; new OSPF
      cryptographic authentication could specify this behavior if desired.
      Alternatively implementations can limit the source addresses from which
      they accept packets. Non-hello packets need only be accepted from
      existing neighbors. If a system is under attack hello packets from
      existing neighbors could be prioritized over hellos from new neighbors.
      These mechanisms can be considered to limit the potential impact of
      denial of service attacks on the cryptographic authentication mechanism
      itself.</t>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Funding for Sam Hartman's work on this memo is provided by
      Huawei.</t>

      <t>The authors would like to thank Ran Atkinson, Michael Barnes, and
      Manav Bhatia for valuable comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4552'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6518'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-threats-reqs'?>
    </references>

    <references title="Informative References">
      <reference anchor="FIPS180">
        <front>
          <title>Secure Hash Standard (SHS)</title>

          <author fullname="US National Institute of Standards and Technology">
            <organization>US National Institute of Standards and
            Technology</organization>
          </author>

          <date month="August" year="2002"/>
        </front>
      </reference>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-ops-model'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-crypto-key-table'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-routing-protocols-crypto-issues'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rpsec-ospf-vuln'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-security-extension-manual-keying'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2154'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6506'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5082'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6039'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4222'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5709'?>

    </references>
  </back>
</rfc>
