idnits 2.17.00 (12 Aug 2021) /tmp/idnits50837/draft-mcbride-rtgwg-bgp-blockchain-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (27 April 2022) is 17 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. McBride 3 Internet-Draft Futurewei 4 Intended status: Informational 27 April 2022 5 Expires: 29 October 2022 7 BGP Blockchain 8 draft-mcbride-rtgwg-bgp-blockchain-00 10 Abstract 12 A variety of mechanisms have been developed and deployed over the 13 years to secure BGP including the more recent RPKI/ROA mechanisms. 14 Is it also possible to use a distributed ledger such as Blockchain to 15 secure BGP? BGP provides decentralized connectivity across the 16 Internet. Blockchain provides decentralized secure transactions in a 17 append-only, tamper-resistant ledger. This document reviews possible 18 opportunities of using Blockchain to secure BGP policies within a 19 domain and across the global Internet. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 29 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Proposed Blockchain for BGP solutions . . . . . . . . . . . . 3 57 2.1. Blockchain to prevent fraudulent BGP origin 58 announcements . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Blockchain to validate incoming BGP updates . . . . . . . 3 60 2.3. Blockchain to provide routing policy such as QoS . . . . 3 61 2.4. Blockchain to protect BGP files . . . . . . . . . . . . . 3 62 2.5. Blockchain to provide path validation . . . . . . . . . . 4 63 2.6. Blockchain for BGP Controllers . . . . . . . . . . . . . 4 64 3. Blockchain compromised by BGP vulnerabilities . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 There have been many proposed solutions to help secure the Border 74 Gateway Protocol (BGP) [RFC4271] including securing TCP, CoPP, IPSec, 75 Secure BGP, Route Origination Validation (ROV), BGPSec along with 76 many variations. Could we also use Blockchain to secure BGP? This 77 document provides a review of how Blockchain could be used to secure 78 BGP particularly as supplemental to existing solutions. Many of the 79 proposals can be extended to any routing protocol but the focus here 80 is with BGP. The potential attractiveness of adding Blockchain to 81 BGP is that it adds additional security without changes to the BGP 82 protocol. This analysis does not consider external factors such as 83 the energy demands of deploying such solutions. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Proposed Blockchain for BGP solutions 93 There are various ways Blockchain could be used to help secure BGP 94 that we will explore in this section. 96 2.1. Blockchain to prevent fraudulent BGP origin announcements 98 Prefix origin announcements could be stored on a blockchain to avoid 99 BGP human configuration errors or hijacks. The consensus algorithms 100 will ensure that everyone knows the correct owner AS of the prefix 101 and everyone will know if there is an unauthorized change attempt. 102 The existing RPKI system could be used to to authorize prefix owners 103 and then an additional step could be to treat that as a transaction 104 to be stored on a blockchain. ROA entries could be added to a 105 blockchain as secure transactions and those transactions would be 106 relied upon by route validators as authoritative. Perhaps blockchain 107 validation information could be added as a new ROA field. 109 2.2. Blockchain to validate incoming BGP updates 111 This is very similar to the previous solution. If using RPKI, route 112 validators could cross check with the BGP blockchain before sending 113 authorized prefix/AS matches to relying BGP routers. If not using 114 RPKI, then routers would need to check a IRR blockchain prefix/AS 115 database, if one were to exist, in order to validate incoming BGP 116 updates. 118 2.3. Blockchain to provide routing policy such as QoS 120 In addition to the prefix to AS match information being stored on a 121 blockchain, the routing policy of those routes could also be stored 122 on the blockchain. As long as the policy was correctly added to the 123 chain, the path policies cannot be altered except by those 124 authenticated to do so. 126 2.4. Blockchain to protect BGP files 128 Blockchain could also be used to store configuration files within an 129 AS in order to prevent malicious config tampering and to prevent 130 misconfiguration. This protection could be provided within a private 131 blockchain environment where only authorized users have access to the 132 blockchain data. This could also be used within a trusted external 133 peering environment to build a distributed database of BGP files such 134 as communities for use between BGP neighbors. Peers can use the data 135 in the blockchain to understand the necessary peering relationship 136 and act on the communities in a consistent manner. 138 2.5. Blockchain to provide path validation 140 BGP stores multiple paths to a destination in the BGP table. The BGP 141 table contains all of the routes from all of the neighbors. Only the 142 best route gets installed in the routing table. To help further 143 secure the BGP table, all of those routes/paths could be installed in 144 a blockchain. Some mechanism could be used to validate these routes/ 145 paths, that reside in the blockchain, prior to one being selected as 146 the path path in the routing table. This could also be extended to 147 provide proof of transit across certain expected paths. 149 2.6. Blockchain for BGP Controllers 151 BGP-LS is used to provide BGP topology information to a Controller. 152 That topology information could be added to a blockchain to ensure 153 that the topology data is not compromised. PCEP, or other protocol, 154 could be used by a controller to validate any update of a BGP 155 forwarding table using this same (or separate) blockchain. The 156 latest forwarding rules would be maintained in a distributed 157 blockchain which is built using BGP-LS data and authorized users as 158 an input. Without the proper credentials it would be very difficult 159 to update the forwarding rules in the blockchain and a record would 160 be kept with all update attempts. 162 3. Blockchain compromised by BGP vulnerabilities 164 The attractiveness of Blockchain applications, such as Bitcoin and 165 Ethereum, are that they are highly decentralized and more resistant 166 to attack. This has opened the way for securing monetary 167 transactions using crytocurrencies and their underlying blockchain 168 technology. Blockchains mining power, however, is centralized with 169 mining pools concentrating within certain regions and Autonomous 170 Systems. This also creates a more centralized routing situation 171 which could become vulnerable to BGP vulerabilities where IP 172 addresses of the mining pools are hijacked. Therefore helping to 173 further secure BGP will help to secure blockchain's centralized 174 mining pools. 176 4. IANA Considerations 178 N/A 180 5. Security Considerations 182 There could be new blockchain related attacks that BGP would 183 experience if blockchain were to be added into BGP's policy system. 184 These attacks include trying to replace the trusted chain with a 185 fradulent chain. We will explore some of those here or in a new 186 draft. 188 6. Acknowledgement 190 7. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 198 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 199 DOI 10.17487/RFC4271, January 2006, 200 . 202 Author's Address 204 Mike McBride 205 Futurewei 206 Email: michael.mcbride@futurewei.com