Network Working Group M. Bhatia
Internet-Draft Alcatel-Lucent
Intended status: Standards Track D. Zhang
Expires: October 14, 2011 Huawei Technologies co., LTD.
April 12, 2011
Analysis of Bidirectional Forwarding Detection (BFD) Security According
to KARP Design Guide
draft-bhatia-zhang-karp-bfd-analysis-00
Abstract
This document analyzes the Bidirectional Forwarding Detection
protocol (BFD) according to the guidelines set forth in section 4.2
of draft-ietf-karp-design-guide.
Bhatia & Zhang Expires October 14, 2011 [Page 1]
Internet-Draft BFD Gap Analysis April 2011
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 14, 2011.
Copyright Notice
Copyright (c) 2011 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
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 Simplified BSD License.
Bhatia & Zhang Expires October 14, 2011 [Page 2]
Internet-Draft BFD Gap Analysis April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements to Meet . . . . . . . . . . . . . . . . . . . . . 5
3. Current State . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Impacts of BFD Replays . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Bhatia & Zhang Expires October 14, 2011 [Page 3]
Internet-Draft BFD Gap Analysis April 2011
1. Introduction
This document performs a gap analysis of the current state of BFD
[RFC5880] according to the requirements of
[I-D.ietf-karp-design-guide]. Previously, the OPSEC working group
has provided an analysis of cryptographic issues with BFD in
[RFC6039].
The existing BFD specifications provide a very initial security
solution. Key ID is provided so that the key used in securing a
packet can be changed on demand. Two cryptographic algorithms (MD5
and SHA-1) are supported for Integrity protection of the control
packets; the algorithms are both demonstrated to be subject to
collision attacks. While these attacks will not necessarily affect
BFD, other routing protocols like RIPv2 [RFC4822], IS-IS [RFC5310]
and OSPFv2 [RFC5709] have moved to stronger algorithms and it is
imperative that BFD also does that as it does not make much sense to
secure these routing protocols with a stronger authentication
algorithm if BFD continues using a weaker security algorithm.
While BFD uses a non-decreasing per-packet sequence number to protect
itself from intra-connection replay attacks, it still leaves the
protocol vulnerable to the inter-session replay attacks.
Bhatia & Zhang Expires October 14, 2011 [Page 4]
Internet-Draft BFD Gap Analysis April 2011
2. Requirements to Meet
There are several requirements described in section 3 of
[I-D.ietf-karp-threats-reqs] that BFD does not currently meet:
Replay Protection: BFD provides an incomplete intra-session and no
inter-session replay attack protection; this creates significant
denial-of-service opportunities.
Strong Algorithms: the cryptographic algorithms adopted for
message authentication in BFD are MD5 or SHA-1 based. However,
both algorithms known to be vulnerable to collision attacks.
[I-D.bhatia-bfd-crypto-auth] proposes a solution to support HMAC
with the SHA-1 and SHA-2 family of hash functions for BFD.
DoS Attacks: BFD packets can be sent at millisecond intervals (the
protocol uses timers at microsecond intervals). When malicious
packets are sent at short intervals, with the authentication bit
set, it can cause a DoS attack.
The remainder of this document explains the details of how these
requirements fail to be met and proposes mechanisms for addressing
them.
Bhatia & Zhang Expires October 14, 2011 [Page 5]
Internet-Draft BFD Gap Analysis April 2011
3. Current State
[RFC5880] describes five authentication mechanisms for the integrity
protection of BFD control packets: Simple Password, Keyed MD5
[RFC1321], Meticulous Keyed MD5, Keyed SHA-1 and Meticulous SHA-1.
In the simple password mechanism, every control packet is associated
with a password transported in plain text; attacks eavesdropping the
network traffic can easily learn the password and compromise the
security of the corresponding BFD session. In the Keyed MD5 and the
Meticulous Keyed MD5 mechanisms, BFD nodes use share secret keys to
generate keyed MD5 digests for control packets. Similarly, in the
Keyed SHA-1 and the Meticulous Keyed SHA-1 mechanisms, BFD nodes use
shared secret keys to generate keyed SHA-1 digests for control
packets. Note that in the keyed authentication mechanisms, every BFD
control packet is associated with a non-decreasing 32-bit sequence
number to resist replay attacks. In the Keyed MD5 and the Keyed
SHA-1 mechanisms, the sequence member is only required to increase
occasionally. However, in the Meticulous Keyed MD5 and the
Meticulous Keyed SHA-1 mechanisms, the sequence member is required to
monotonically increase with each succesive packet.
Additionally, limited key updating functionality is provided. There
is a Key ID in every authenticated BFD control packet, indicating the
key used to hash the packet. However, there is no mechanism
described to provide a smooth key rollover that the BFD routers can
use when moving from one key to the other.
It is common to send BFD packets at microsecond and millisecond
intervals. Since the cryptographic sequence number space is only 32
bits, it will not take very long for the sequence space to reach its
maximum value and roll over. This can result in potential inter-
session replay attacks. This exacerbates when BFD uses the
meticulous authentication mode.
In a BFD session, each nodes needs to select a 32-bit discriminator
to identify itself. Therefore, a BFD session is identified by two
discriminators. If a node will randomly select a new discriminator
for a new session and use authentication mechanism to secure the
control packets, inter-session replay attacks can be mitigated to
some extent. However, in existing BFD demultiplexing mechanisms, the
discriminators used in a new BFD session may be predicable. This
issue may be taken advantage of by attackers to perform replay
attacks.
BFD allows a mode called the echo mode. Echo packets are not defined
in the BFD specification, though they can keep the BFD session up.
The format of the echo packet is local to the sending side and there
are no guidelines on the properties of these packets beyond the
Bhatia & Zhang Expires October 14, 2011 [Page 6]
Internet-Draft BFD Gap Analysis April 2011
choice of the source and destination addresses. While the BFD
specification recommends applying security mechanisms to prevent
spoofing of these packets, there are no guidelines on what type of
mechanisms are appropriate.
Bhatia & Zhang Expires October 14, 2011 [Page 7]
Internet-Draft BFD Gap Analysis April 2011
4. Impacts of BFD Replays
As discussed, BFD cannot meet the requirements of inter-session or
intra-session replay protection. This section discusses the impacts
of BFD replays.
When cryptographic authentication mechanisms are adopted for BFD, a
non-decreasing 32-bit long sequence number is used. In the Keyed MD5
and the Keyed SHA-1 mechanisms, the sequence member is not required
to increase for every packet. Therefore an attacker can keep
replaying the packets with the latest sequence number until the
sequence number is updated. This issue is eliminated in the
Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 mechanisms.
However, note that a sequence number may reach its maximum and be
rolled over in a session. In this case, without the support from a
automatic key management mechanism, the BFD session will be
vulnerable to replay attacks performed by sending the packets before
the roll over of the sequence number. Because the BFD specification
allows for the change of authentication state based on the state of a
received packet, an elaborately selected replayed packet can cause a
serious denial-of-service attack. For instance, an attacker can
replay a packet in which the sequence number is much larger than the
current one to convince a node that large amount of packets has been
lost. As a result, the victim will transfer its state to down.
BFD does not provide any solution to deal with inter-session replay
attacks. Although discriminators can potentially be used to
challenge the aliveness of node on the other side of new BFD session,
The method of demultiplexing the initial packets is not specified.
If two subsequent BFD sessions adopt an identical discriminator pair
and use same cryptographic key to secure the control packets, a
malicious authenticated packet (stored from the past session) can be
used to perform inter-connection replay attacks.
Any security issues in the BFD echo mode will directly affect the BFD
protocol and session states, and hence the network stability. For
instance, any replay attacks would be indistinguishable from normal
forwarding of the tested router. An attack would still cause a
faulty link to be believed to be up, but there is little that can be
done about it. However, if the echo packets are guessable, it may be
possible to spoof from an external source and cause BFD to believe
that a one-way link is really bidirectional. As a result, it is
important that the echo packets contain random material that is also
checked upon reception.
Bhatia & Zhang Expires October 14, 2011 [Page 8]
Internet-Draft BFD Gap Analysis April 2011
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Bhatia & Zhang Expires October 14, 2011 [Page 9]
Internet-Draft BFD Gap Analysis April 2011
6. Security Considerations
Bhatia & Zhang Expires October 14, 2011 [Page 10]
Internet-Draft BFD Gap Analysis April 2011
7. Acknowledgements
Bhatia & Zhang Expires October 14, 2011 [Page 11]
Internet-Draft BFD Gap Analysis April 2011
8. References
8.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010.
8.2. Informative References
[I-D.bhatia-bfd-crypto-auth]
Bhatia, M. and V. Manral, "BFD Generic Cryptographic
Authentication", draft-bhatia-bfd-crypto-auth-03 (work in
progress), January 2011.
[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-02 (work in progress),
March 2011.
[I-D.ietf-karp-threats-reqs]
Lebovitz, G., Bhatia, M., and R. White, "The Threat
Analysis and Requirements for Cryptographic Authentication
of Routing Protocols' Transports",
draft-ietf-karp-threats-reqs-01 (work in progress),
October 2010.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[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.
Bhatia & Zhang Expires October 14, 2011 [Page 12]
Internet-Draft BFD Gap Analysis April 2011
Authors' Addresses
Manav Bhatia
Alcatel-Lucent
Bangalore,
India
Phone:
Email: manav.bhatia@alcatel-lucent.com
Dacheng Zhang
Huawei Technologies co., LTD.
Beijing,
China
Phone:
Fax:
Email: zhangdacheng@huawei.com
URI:
Bhatia & Zhang Expires October 14, 2011 [Page 13]