Network Working Group S. Hartman
Internet-Draft Painless Security
Intended status: Informational D. Zhang
Expires: December 26, 2010 Huawei
June 24, 2010
Analysis of OSPF Security According to KARP Design Guide
draft-hartman-ospf-analysis-01.txt
Abstract
This document analyzes OSPFv2 and OSPFv3 according to the guidelines
set forth in section 4.2 of draft-ietf-karp-design-guide.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Hartman & Zhang Expires December 26, 2010 [Page 1]
Internet-Draft OSPF Analysis June 2010
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Current State . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Replay Detection . . . . . . . . . . . . . . . . . . . . . . . 7
5. IP Layer Issues . . . . . . . . . . . . . . . . . . . . . . . 9
6. Packet Prioritization . . . . . . . . . . . . . . . . . . . . 10
7. OSPF Security Requirements . . . . . . . . . . . . . . . . . . 11
8. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. OSPFv2 Replay Mechanism . . . . . . . . . . . . . . . . . 12
8.2. OSPFv3 Replay . . . . . . . . . . . . . . . . . . . . . . 12
8.3. IP Header . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Hartman & Zhang Expires December 26, 2010 [Page 2]
Internet-Draft OSPF Analysis June 2010
1. Introduction
This document performs the initial analysis of the current state of
OSPFv2 and OSPFv3 according to the requirements of
[I-D.ietf-karp-design-guide]. This draft builds on several previous
analysis efforts into routing security. The OPSEC working group put
together [I-D.ietf-opsec-routing-protocols-crypto-issues] an analysis
of cryptographic issues with routing protocols. Earlier, the RPSEC
working group put together [I-D.ietf-rpsec-ospf-vuln] a detailed
analysis of OSPF vulnerabilities.
Hartman & Zhang Expires December 26, 2010 [Page 3]
Internet-Draft OSPF Analysis June 2010
2. Requirements notation
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].
Hartman & Zhang Expires December 26, 2010 [Page 4]
Internet-Draft OSPF Analysis June 2010
3. Current State
This section describes the security mechanisms built into OSPFv2 and
OSPFv3.
3.1. OSPFv2
Appendix D of [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.
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.
RFC 5709 [RFC5709] adds support for the SHA [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.
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
Section 4 for discussion of the impacts of these replay attacks.
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.
3.2. OSPFv3
RFC 4552 [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.
Hartman & Zhang Expires December 26, 2010 [Page 5]
Internet-Draft OSPF Analysis June 2010
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.
Because manual keying is used, no replay protection is provided for
OSPFv3.
Hartman & Zhang Expires December 26, 2010 [Page 6]
Internet-Draft OSPF Analysis June 2010
4. Replay Detection
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.
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 [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.
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.
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.
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
Hartman & Zhang Expires December 26, 2010 [Page 7]
Internet-Draft OSPF Analysis June 2010
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.
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.
Hartman & Zhang Expires December 26, 2010 [Page 8]
Internet-Draft OSPF Analysis June 2010
5. IP Layer Issues
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.
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.
Hartman & Zhang Expires December 26, 2010 [Page 9]
Internet-Draft OSPF Analysis June 2010
6. Packet Prioritization
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.
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.
Hartman & Zhang Expires December 26, 2010 [Page 10]
Internet-Draft OSPF Analysis June 2010
7. OSPF Security Requirements
This section describes requirements for OSPF security that should be
met within the routing protocol.
As with all routing protocols, per-packet protection with a
cryptographic MAC is required.
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.
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.
Hartman & Zhang Expires December 26, 2010 [Page 11]
Internet-Draft OSPF Analysis June 2010
8. Gap Analysis
8.1. OSPFv2 Replay Mechanism
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
Section 4, this strategy creates several opportunities for attack.
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.
8.2. OSPFv3 Replay
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.
8.3. IP Header
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.
Hartman & Zhang Expires December 26, 2010 [Page 12]
Internet-Draft OSPF Analysis June 2010
9. Security Considerations
This memo discusses and compiles vulnerabilities in the existing OSPF
cryptographic handling.
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
[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.
Hartman & Zhang Expires December 26, 2010 [Page 13]
Internet-Draft OSPF Analysis June 2010
10. Acknowledgments
Funding for Sam Hartman's work on this memo is provided by Huawei.
The authors would like to thank Ran Atkinson and Manav Bhatia for
valuable comments.
Hartman & Zhang Expires December 26, 2010 [Page 14]
Internet-Draft OSPF Analysis June 2010
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009.
11.2. Informative References
[FIPS180] US National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", August 2002.
[I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-00 (work in progress),
February 2010.
[I-D.ietf-opsec-routing-protocols-crypto-issues]
Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R.
White, "Issues with existing Cryptographic Protection
Methods for Routing Protocols",
draft-ietf-opsec-routing-protocols-crypto-issues-06 (work
in progress), June 2010.
[I-D.ietf-rpsec-ospf-vuln]
Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in
progress), June 2006.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
Hartman & Zhang Expires December 26, 2010 [Page 15]
Internet-Draft OSPF Analysis June 2010
Authors' Addresses
Sam Hartman
Painless Security
Email: hartmans-ietf@mit.edu
Dacheng Zhang
Huawei
Email: zhangdacheng@huawei.com
Hartman & Zhang Expires December 26, 2010 [Page 16]