One document matched: draft-ietf-karp-ospf-analysis-03.xml
<?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-03.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></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 draft-ietf-karp-design-guide.</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 performs the initial analysis of 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.</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> the requirements. 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:<list style="empty">
<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.hartman-karp-ops-model"></xref> are
possible.</t>
<t>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.</t>
<t>Packet Prioritization: OSPFv3 uses IPsec 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"></xref> 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"></xref> adds support for
the SHA <xref target="FIPS180"></xref> 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
implementation use, e.g., "seconds since reboot" as their sequence
numbers. The sequence numbers is thus only increased by every second.
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"></xref>, 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"></xref>, this
issue is addressed by changing the definition of Apad from a constant
defined in <xref target="RFC5709"></xref> 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"></xref> regarding
lifetime.</t>
<t>The OSPFv2 replay mechanism does not handle packet priorities as
described. If packets are processed out-of-order, then if the sequence
number increases, packets processed later will be discarded.</t>
</section>
<section title="OSPFv3">
<t>RFC 4552 <xref target="RFC4552"></xref> 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. This mechanism meets requirements
related to algorithm selection and agility.</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, 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. 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, 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"></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 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 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, the information needed to
prioritize OSPF packets (the packet type) MUST be at a constant location
in the packet.</t>
<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></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. RFC 2154 <xref
target="RFC2154"></xref> 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>
<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.5709'?>
</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.hartman-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-karp-threats-reqs'?>
<?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.5082'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6518'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6039'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:30 |