One document matched: draft-hartman-ospf-analysis-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY RFC4552 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4552.xml'>
    <!ENTITY RFC2328 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml'>
    <!ENTITY RFC2154 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2154.xml'>
 <!ENTITY RFC5709 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5709.xml'>
]>


<rfc category="info" ipr="trust200902" docName="draft-hartman-ospf-analysis-01.txt">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
        <title abbrev="OSPF Analysis">Analysis of OSPF Security According to KARP Design Guide</title>
    <author initials="S." surname="Hartman" fullname="Sam Hartman">
      <organization>Painless Security</organization>
      <address>
	<email>hartmans-ietf@mit.edu</email>
      </address>
    </author>
    <author initials="D." surname="Zhang" fullname="Dacheng Zhang">
      <organization>Huawei</organization>
      <address>
	<email>zhangdacheng@huawei.com</email>
      </address>
    </author>
        <date/>
    <abstract>
      <t>This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide.</t>
    </abstract>
    </front>

    <middle>
    <section title="Introduction">
      <t>This document performs the initial analysis of the current state of OSPFv2 and OSPFv3 according to the requirements of <xref target="I-D.ietf-karp-design-guide"/>.  This draft builds on several previous analysis efforts into routing security.  The OPSEC working group put together <xref target="I-D.ietf-opsec-routing-protocols-crypto-issues"/> an analysis of cryptographic issues with routing protocols. Earlier, the RPSEC working group put together <xref target="I-D.ietf-rpsec-ospf-vuln"/> a detailed analysis of OSPF vulnerabilities.</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 <xref target="RFC2119"/>.</t>
        </section>

    <section title="Current State">
      <t>This section describes the security mechanisms built into OSPFv2 and OSPFv3.
</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.</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>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. In order to provide cryptographic algorithms beleived 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. See <xref target="REPLAY"/> for discussion of the impacts of these replay attacks.</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.</t>

      </section>
      <section title="OSPFv3">
	<t>RFC 4552 <xref target="RFC4552"/> describes how the 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.</t>
	<t>The Security Parameter Index (SPI) provides an identifier for the security association.  This along with other IPsec facilities provides a mechanism for moving from one key to another.</t>
	<t>Because manual keying is used, no replay protection is provided for OSPFv3.</t>

      </section>
    </section>
    <section anchor="REPLAY" title="Replay Detection">
      <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.</t> 
      <t>While the LSA sequence number provides some defense, there
      are a number of attacks that are possible because of a
      per-packet replay. The RPSEC analysis <xref
      target="I-D.ietf-rpsec-ospf-vuln"/> 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 age. 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 ligitimate 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="IP Layer Issues">
      <t>The OSPFv2 cryptographic authentication does not include the
      IP header. So, fields like the source address are not
      protected. The OSPF specification uses the source address in
      some locations: for some network types, the source address is
      used to match which neighbor a packet is from. Changing the
      source address of a packet can produce a number of denial of
      service attacks. If the packet is interpreted as coming from a
      different neighbor, the sequence number received from the
      neighbor may be updated. This may disrupt communication with the
      legitimate neighbor. Hello packets may be reflected to cause a
      neighbor to appear to have one-way communication. Old Database
      descriptions may be reflected in cases where the per-packet
      sequence numbers are sufficiently divergent in order to disrupt
      an adjacency.</t>
      <t>RFC 4552 requires the support of ESP and permits the use of
      AH. ESP does not provide any protection of the IP source
      address . Ah does provide such protection.Similarly, ESP does not provide protection against
        the insertion, deletion, or modification of any
        optional IPv6 headers in the OSPFv3 packet,
        while AH does provide that protection.</t>
    </section>
    <section title="Packet Prioritization">
      <t>OSPF implementations generally prioritize packets in order to
      minimize disruption when router resources such as CPU or memory
      experience contention. This can cause complications for the
      OSPFv2 packet replay mechanism. As specified, if packets are
      processed out-of-order, then the skipped packets may be
      discarded if the sequence number increased. Refinements to the
      replay mechanism need to keep this usage in mind.</t>
      <t>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 title="OSPF Security Requirements">
      <t>This section describes requirements for OSPF security that should be met within the routing protocol.</t>
      <t>As with all routing protocols, per-packet protection with a cryptographic MAC is required.</t>
      <t>Mechanisms are required in order to support key rollover.
      Multiple approaches could be used.  However since the existing
      mechanisms provide a protocol field to identify the key as well
      as management mechanisms to introduce and retire new keys,
      focusing on the existing mechanism as a starting point is prudent.</t>
      <t>Replay protection is required. The replay mechanism needs to
      be sufficient to prevent an attacker from creating a denial of
      service or disrupting the integrity of the routing protocol by
      replaying packets. It is important that an attacker not be able
      to disrupt service by capturing packets and waiting for replay
      state to be lost.</t>

    </section>
    <section title="Gap Analysis">
      <section title="OSPFv2 Replay Mechanism">
	<t>The OSPFv2 mechanism allows an attacker to replay packets
	until the sequence number increases.  Implementations are
	expected to increase their sequence number once a second or
	so. As discussed in <xref target="REPLAY"/>, this strategy
	creates several opportunities for attack.</t>
	<t>In order to avoid significant denial of service issues, the
	replay mechanism needs to be improved. Part of this
	improvement may come simply from rules about when the sequence
	number should be increased. Other improvements are required to
	prevent attacks where  an old replay is made either when an
	adjacency is down or from a time when a sequence number is
	significantly greater than the current sequence number to
	disrupt an association.</t>
      </section>
      <section title="OSPFv3 Replay">
	<t>The replay vulnerabilities for OSPFv3 are greater than for
	OSPFv2. There is no mechanism providing replay protection at
	all. Even for manual keying, some replay mechanism is required.</t>
      </section>
      <section title="IP Header">
	<t>OSPF depends on fields in the IP header, particularly the
	source address. These fields are not integrity protected. This
	interacts particularly badly with the OSPFv2 replay mechanism,
	although other attacks are also possible.</t>
      </section>
    </section>
        <section 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.  RFC 2154 <xref
      target="RFC2154"/> provides an experimental solution for
      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>
        </section>
    <section title="Acknowledgments">
      <t>Funding for Sam Hartman's work on this memo is provided by Huawei.</t>
      <t>The authors would like to thank Ran Atkinson and Manav Bhatia
      for valuable comments.</t>
    </section>
    </middle>

    <back>
        <references title='Normative References'>
&rfc2119;
      &RFC2328;
      &RFC4552;
      &RFC5709;
    </references>
    <references title="Informative References">
      &RFC2154;
      <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>
<reference anchor='I-D.ietf-karp-design-guide'>
<front>
<title>Keying and Authentication for Routing Protocols (KARP) Design Guidelines</title>

<author initials='G' surname='Lebovitz' fullname='Gregory Lebovitz'>
    <organization />
</author>

<author initials='M' surname='Bhatia' fullname='Manav Bhatia'>
    <organization />
</author>

<date month='February' day='25' year='2010' />

<abstract><t>In the March of 2006 the IAB held a workshop on the topic of "Unwanted Internet Traffic".  The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for [t]ightening the security of the core routing infrastructure."  Four main steps were identified for improving the security of the routing infrastructure. One of those steps was "securing the routing protocols' packets on the wire."  One mechanism for securing routing protocol packets on the wire is the use of per-packet cryptographic message authentication, providing both peer authentication and message integrity.  Many different routing protocols exist and they employ a range of different transport subsystems.  Therefore there must necessarily be various methods defined for applying cryptographic authentication to these varying protocols.  Many routing protocols already have some method for accomplishing cryptographic message authentication.  However, in many cases the existing methods are dated, vulnerable to attack, and/or employ cryptographic algorithms that have been deprecated.  This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols.  In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity.  The overall roadmap reflects the input of both the security area and routing area in order to form a jointly agreed upon and prioritized work list for the effort.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-karp-design-guide-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-00.txt' />
</reference>

<reference anchor='I-D.ietf-opsec-routing-protocols-crypto-issues'>
<front>
<title>Issues with existing Cryptographic Protection Methods for Routing Protocols</title>

<author initials='J' surname='Jaeggli' fullname='Joel Jaeggli'>
    <organization />
</author>

<author initials='S' surname='Hares' fullname='Susan Hares'>
    <organization />
</author>

<author initials='M' surname='Bhatia' fullname='Manav Bhatia'>
    <organization />
</author>

<author initials='V' surname='Manral' fullname='Vishwas Manral'>
    <organization />
</author>

<author initials='R' surname='White' fullname='Russ White'>
    <organization />
</author>

<date month='June' day='9' year='2010' />

<abstract><t>Routing protocols have over time been extended to use cryptographic mechanisms to validate data being received from a neighboring router to ensure that:  o It has not been modified in transit. o Actually originated from an authorized neighboring router.  The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.  This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-opsec-routing-protocols-crypto-issues-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-opsec-routing-protocols-crypto-issues-06.txt' />
</reference>

<reference anchor='I-D.ietf-rpsec-ospf-vuln'>
<front>
<title>OSPF Security Vulnerabilities Analysis</title>

<author initials='E' surname='Jones' fullname='Emanuele Jones'>
    <organization />
</author>

<author initials='O' surname='Moigne' fullname='Olivier Le Moigne'>
    <organization />
</author>

<date month='June' day='19' year='2006' />

<abstract><t>Internet infrastructure protocols were designed at the very early stages of computer networks when "cyberspace" was still perceived as a benign environment. As a consequence, malicious attacks were not considered to be a major risk when these protocols were designed, leaving today's Internet vulnerable. This paper provides an analysis of OSPF vulnerabilities that could be exploited to modify the normal routing process across a single domain together with an assessment of when internal OSPF mechanisms can or cannot be leveraged to better secure a domain.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rpsec-ospf-vuln-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rpsec-ospf-vuln-02.txt' />
</reference>

    </references>
    </back>

</rfc>