Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines
RFC 7492
| Document | Type |
RFC - Informational
(March 2015; No errata)
Was draft-ietf-karp-bfd-analysis (individual in rtg area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-bhatia-zhang-karp-bfd-analysis | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | WG Document | |
| Document shepherd | Brian Weis | ||
| Shepherd write-up | Show (last changed 2014-07-01) | ||
| IESG | IESG state | RFC 7492 (Informational) | |
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Adrian Farrel | ||
| IESG note | Processing as AD Sponsored as KARP working group has closed down. | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IANA Actions | ||
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7492 Ionos Networks
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei
M. Jethanandani
Ciena Corporation
March 2015
Analysis of Bidirectional Forwarding Detection (BFD) Security
According to the Keying and Authentication for Routing Protocols (KARP)
Design Guidelines
Abstract
This document analyzes the Bidirectional Forwarding Detection (BFD)
protocol according to the guidelines set forth in Section 4.2 of RFC
6518, "Keying and Authentication for Routing Protocols (KARP) Design
Guidelines".
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7492.
Bhatia, et al. Informational [Page 1]
RFC 7492 BFD Gap Analysis March 2015
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements to Meet . . . . . . . . . . . . . . . . . . . . 3
3. Current State of Security Methods . . . . . . . . . . . . . . 3
4. Impacts of BFD Replays . . . . . . . . . . . . . . . . . . . 5
5. Impact of New Authentication Requirements . . . . . . . . . . 6
6. Considerations for Improvement . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document performs a gap analysis of the current state of
Bidirectional Forwarding Detection [RFC5880] according to the
requirements of KARP Design Guidelines [RFC6518]. Previously, the
OPSEC working group has provided an analysis of cryptographic issues
with BFD in "Issues with Existing Cryptographic Protection Methods
for Routing Protocols" [RFC6039].
The existing BFD specifications provide a basic 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.
Routing protocols like "RIPv2 Cryptographic Authentication"
[RFC4822], "IS-IS Generic Cryptographic Authentication" [RFC5310],
and "OSPFv2 HMAC-SHA Cryptographic Authentication" [RFC5709] have
started to use BFD for liveliness checks. Moving the routing
Bhatia, et al. Informational [Page 2]
RFC 7492 BFD Gap Analysis March 2015
protocols to a stronger algorithm while using a weaker algorithm for
BFD would allow the attacker to bring down BFD in order to bring down
the routing protocol. BFD therefore needs to match the routing
protocols in its strength of 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.
Show full document text