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)
|
|
---|---|---|---|
Authors | Manav Bhatia , Dacheng Zhang , Mahesh Jethanandani | ||
Last updated | 2015-10-14 | ||
Replaces | draft-bhatia-zhang-karp-bfd-analysis | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized 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