RFC 7353

Security Requirements for BGP Path Validation

📅 published August 2014, from ietf

RFC 7353: Security Requirements for BGP Path Validation 🎀

Okay bestie, this is RFC 7353, and it's giving routing security 💅. It was published by the Internet Engineering Task Force (IETF) in August 2014. The authors are S. Bellovin (Columbia University), R. Bush (Internet Initiative Japan), and D. Ward (Cisco Systems). It's Informational, not Standards Track, and its ISSN is 2070-1721. The title block doesn't list any RFCs it obsoletes or updates, so it's a standalone doc 🦋.

Abstract ✨

Okay so this doc lays out the requirements for a BGP security protocol design. The goal is cryptographic proof that the origin Autonomous System (AS) is allowed to announce the prefix, plus proof of the AS Path of the announcement. Main character energy 👑.

Status of This Memo 🌸

This doc is not an Internet Standards Track spec. It's published just for info 💖.

It's a product of the IETF, so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that ✨.

For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7353 🧚.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc. Code Components extracted from this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶.

Table of Contents 💜

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
2.  Recommended Reading . . . . . . . . . . . . . . . . . . . . .   2
3.  General Requirements  . . . . . . . . . . . . . . . . . . . .   3
4.  BGP UPDATE Security Requirements  . . . . . . . . . . . . . .   5
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   7

1. Introduction ✨

Okay so origin validation based on the Resource Public Key Infrastructure (RPKI) [RFC6811] gives you a measure of resilience against accidental mis-origination of prefixes 🛡️. BUT it doesn't give cryptographic assurance (announcements aren't signed), and it doesn't give assurance of the AS Path of the announcement either 💀.

This doc describes the requirements for a BGP security protocol, which we're calling "BGPsec", meant to close those gaps 💖.

The threat model assumed here is documented in [RFC4593] and [RFC7132] 🧚.

As the threat model [RFC7132] points out, this work is limited to threats to the BGP protocol. Business relationship conformance matters a lot to operators, but it isn't a security issue per se, so it's out of scope here. The hope is that these issues get better understood in the future 🌸.

1.1. Requirements Language 🎀

Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in RFC 2119 [RFC2119] only when they show up in ALL CAPS. They can also appear in lower or mixed case, but then they have no normative meaning 🙈.

This doc assumes you know the RPKI [RFC6480] and the RPKI Repository Structure [RFC6481] 🧠.

It also assumes ongoing incremental deployment of Route Origin Authorizations (ROAs) [RFC6482], the RPKI to the Router Protocol [RFC6810], and RPKI-based Prefix Validation [RFC6811] 🍓.

And of course, you need knowledge of BGP [RFC4271] too 🫶.

3. General Requirements 💅

Here are the general requirements for a BGPsec protocol, bestie 👑:

3.1 A BGPsec design MUST allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the originating AS in the received PATH attribute had the authority to announce the prefix 🔥.

3.2 A BGPsec design MUST allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of External BGP (eBGP) exchanges that propagated the prefix from the origin AS to the receiver. This is especially true if an AS has added or deleted any AS number other than its own in the PATH attribute. It also includes modifications to the number of AS prepends 🦋.

3.3 BGP attributes other than the AS_PATH are used only locally, or only have meaning between immediate neighbors. They may be modified by intermediate systems and figure less prominently in the decision process. So it's not appropriate to try to protect those attributes in a BGPsec design 🌸.

3.4 A BGPsec design MUST be amenable to incremental deployment. This implies that incompatible protocol capabilities MUST be negotiated ✨.

3.5 A BGPsec design MUST provide analysis of the operational considerations for deployment, especially incremental deployment, e.g., contiguous islands, non-contiguous islands, universal deployment, etc. 🧚

3.6 Proofs of possession and authentication may require cryptographic payloads and/or storage and computation. That likely increases processing and memory demands on routers, so a BGPsec design MAY require use of new hardware. In other words, compatibility with current hardware abilities is not a requirement this doc imposes on a solution 💖.

3.7 A BGPsec design need not prevent attacks on data-plane traffic. It need not provide assurance that the data plane even follows the control plane 🙈.

3.8 A BGPsec design MUST resist attacks by an enemy who has access to the inter-router link layer, per Section 3.1.1.2 of [RFC4593]. Specifically, such a design MUST provide mechanisms for authentication of all data, including protection against message insertion, deletion, modification, or replay. Mechanisms that suffice include TCP sessions authenticated with the TCP Authentication Option (TCP-AO) [RFC5925], IPsec [RFC4301], or Transport Layer Security (TLS) [RFC5246] 🔐.

3.9 It's assumed that a BGPsec design will require information about holdings of address space and Autonomous System Numbers (ASNs), plus assertions about binding address space to ASNs. A BGPsec design MAY make use of a security infrastructure (e.g., a PKI) to distribute that authenticated data 🌈.

3.10 Securing AS SETs and prefix aggregation is entirely OPTIONAL. The long-range solution here is deprecating AS_SETs; see [RFC6472] 🍓.

3.11 If a BGPsec design uses signed prefixes, splitting a signed message while keeping the signature intact is hard. So it need not handle multiple prefixes in a single UPDATE PDU 🎀.

3.12 A BGPsec design MUST enable each BGPsec speaker to configure use of the security mechanism on a per-peer basis 👑.

3.13 A BGPsec design MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward-compatible manner 🦋.

3.14 The formal validity of a routing announcement should be determined by the BGPsec protocol. But local routing policy MUST be the final arbiter of the best path and other routing decisions 💅.

3.15 A BGPsec design MUST support 'transparent' route servers, meaning the AS of the route server is not counted in downstream BGP AS-path-length tie-breaking decisions ✨.

3.16 A BGPsec design MUST support AS aliasing. This technique isn't well defined or universally implemented, but it's being documented in [AS-MIGRATION]. A BGPsec design SHOULD accommodate AS 'migration' techniques, such as common proprietary and non-standard methods that let a router have two AS identities without lengthening the effective AS Path 🧚.

3.17 If a BGPsec design makes use of a security infrastructure, that infrastructure SHOULD let each network operator select the entities it will trust when authenticating data in the security infrastructure. See, for example, [LTA-USE-CASES] 🫶.

3.18 A BGPsec design MUST NOT require operators to reveal more than is currently revealed in the operational inter-domain routing environment. The exception is including the necessary security credentials so others can work out for themselves the degree of assurance they need about the validity of Network Layer Reachability Information (NLRI) received via BGPsec. This covers peering, customer/provider relationships, an ISP's internal infrastructure, etc. It's understood that some data is revealed to the savvy seeker by BGP, traceroute, etc., today 🙈.

3.19 A BGPsec design MUST signal (e.g., via logging or SNMP) security exceptions that are significant to the operator. The specific data to be signaled is an implementation matter 🔥.

3.20 Any routing information database MUST be re-authenticated periodically or in an event-driven manner, especially in response to events such as PKI updates 🌸.

3.21 Any inter-AS use of cryptographic hashes or signatures MUST provide mechanisms for algorithm agility. For a discussion, see [ALG-AGILITY] 💖.

3.22 A BGPsec design SHOULD NOT presume to know the intent of the originator of an NLRI, nor that of any AS on the AS Path, other than that they intend to pass it to the next AS in the path 👑.

3.23 A BGPsec listener SHOULD NOT trust non-BGPsec markings, such as communities, across trust boundaries 💅🎀

4. BGP UPDATE Security Requirements ✨

okay so bestie, this section is the big checklist for BGP UPDATE messages 🫶 the following requirements MUST be met when you process them, no cap 💅

  • 4.1 A BGPsec design MUST let every recipient of an UPDATE formally validate that the origin AS in the message is authorized to originate a route to the prefix(es) in the message. 👑
  • 4.2 A BGPsec design MUST let the recipient of an UPDATE formally determine that the NLRI has traversed the AS Path indicated in the UPDATE. ngl this one is extra strict 🙈 It's not enough to show the path is merely not impossible.
  • 4.3 Replay of BGP UPDATE messages doesn't have to be completely prevented 🦋 but a BGPsec design SHOULD provide a mechanism to control the window of exposure to replay attacks.
  • 4.4 A BGPsec design SHOULD provide some level of assurance that the origin of a prefix is still 'alive', i.e., that a monkey in the middle has not withheld a WITHDRAW message or the effects thereof. 😭
  • 4.5 The AS Path of an UPDATE message SHOULD be able to be authenticated as the message is processed. 🌸
  • 4.6 Normal sanity checks of received announcements MUST be done 💖, e.g., verification that the first element of the AS_PATH list corresponds to the locally configured AS of the peer from which the UPDATE was received.
  • 4.7 The output of a router applying BGPsec validation to a received UPDATE MUST be unequivocal and conform to a fully specified state in the design. It's giving "no wiggle room" energy 🍓

5. Security Considerations 💀

okay this part is seriously important, so pay attention bestie 🥺

If an external "security infrastructure" is used, as mentioned in Section 3, paragraphs 9 and 17 above, the authenticity and integrity of the data of such an infrastructure MUST be assured. In addition, the integrity of those data MUST be assured when they are used by BGPsec, e.g., in transport.

The requirement of backward compatibility to BGP4 may open an avenue for downgrade attacks. 😬

The data plane might not follow the path signaled by the control plane. 👀

Security for subscriber traffic is outside the scope of this document and of BGP security in general. IETF standards for payload data security should be employed. While adoption of BGP security measures may ameliorate some classes of attacks on traffic, these measures are not a substitute for use of subscriber-based security. 🔐

6. Acknowledgments 🎀

The authors wish to thank the authors of [BGP-SECURITY] from whom we liberally stole, Roque Gagliano, Russ Housley, Geoff Huston, Steve Kent, Sandy Murphy, Eric Osterweil, John Scudder, Kotikalapudi Sriram, Sam Weiler, and a number of others. 🫶✨

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
           Routing Protocols", RFC 4593, October 2006.

[RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
           Authentication Option", RFC 5925, June 2010.

[RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
           RFC 7132, February 2014.

7.2. Informative References

[ALG-AGILITY]
           Housley, R., "Guidelines for Cryptographic Algorithm
           Agility", Work in Progress, June 2014.

[AS-MIGRATION]
           George, W. and S. Amante, "Autonomous System (AS)
           Migration Features and Their Effects on the BGP AS_PATH
           Attribute", Work in Progress, January 2014.

[BGP-SECURITY]
           Christian, B. and T. Tauber, "BGP Security Requirements",
           Work in Progress, November 2008.

[LTA-USE-CASES]
           Bush, R., "RPKI Local Trust Anchor Use Cases", Work in
           Progress, June 2014.

[RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
           Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
           Internet Protocol", RFC 4301, December 2005.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC6472]  Kumari, W. and K. Sriram, "Recommendation for Not Using
           AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
           December 2011.

[RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
           Secure Internet Routing", RFC 6480, February 2012.

[RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
           Resource Certificate Repository Structure", RFC 6481,
           February 2012.

[RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
           Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
           Infrastructure (RPKI) to Router Protocol", RFC 6810,
           January 2013.

[RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
           Austein, "BGP Prefix Origin Validation", RFC 6811, January
           2013.

Authors' Addresses 📮

Steven M. Bellovin
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, New York  10027
USA

Phone: +1 212 939 7149
EMail: bellovin@acm.org
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington  98110
USA

EMail: randy@psg.com
David Ward
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
USA

EMail: dward@cisco.com
📦 where this page comes from