idnits 2.17.1 draft-ietf-sidr-bgpsec-reqs-12.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 14, 2014) is 3567 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ga-idr-as-migration-01 == Outdated reference: A later version (-08) exists of draft-iab-crypto-alg-agility-01 == Outdated reference: A later version (-07) exists of draft-ietf-sidr-lta-use-cases-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bellovin 3 Internet-Draft Columbia University 4 Intended status: Informational R. Bush 5 Expires: January 15, 2015 Internet Initiative Japan 6 D. Ward 7 Cisco Systems 8 July 14, 2014 10 Security Requirements for BGP Path Validation 11 draft-ietf-sidr-bgpsec-reqs-12 13 Abstract 15 This document describes requirements for a BGP security protocol 16 design to provide cryptographic assurance that the origin AS 17 (Autonomous System) had the right to announce the prefix and to 18 provide assurance of the AS Path of the announcement. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 24 be interpreted as described in RFC 2119 [RFC2119] only when they 25 appear in all upper case. They may also appear in lower or mixed 26 case as English words, without normative meaning. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 15, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Recommended Reading . . . . . . . . . . . . . . . . . . . . . 3 64 3. General Requirements . . . . . . . . . . . . . . . . . . . . 3 65 4. BGP UPDATE Security Requirements . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Resource Public Key Infrastructure (RPKI)-based Origin Validation, 77 [RFC6811], provides a measure of resilience to accidental mis- 78 origination of prefixes. But it provides neither cryptographic 79 assurance (announcements are not signed), nor assurance of the AS 80 Path of the announcement. 82 This document describes requirements to be placed on a BGP security 83 protocol, herein termed BGPsec, intended to rectify these gaps. 85 The threat model assumed here is documented in [RFC4593] and 86 [RFC7132]. 88 As noted in the threat model, [RFC7132], this work is limited to 89 threats to the BGP protocol. Issues of business relationship 90 conformance, while quite important to operators, are not security 91 issues per se, and are outside the scope of this document. It is 92 hoped that these issues will be better understood in the future. 94 2. Recommended Reading 96 This document assumes knowledge of the RPKI see [RFC6480], the RPKI 97 Repository Structure, see [RFC6481]. 99 This document assumes ongoing incremental deployment of ROAs, see 100 [RFC6482], the RPKI to Router Protocol, see [RFC6810], and RPKI-based 101 Prefix Validation, see [RFC6811]. 103 And, of course, a knowledge of BGP [RFC4271] is required. 105 3. General Requirements 107 The following are general requirements for a BGPsec protocol: 109 3.1 A BGPsec design MUST allow the receiver of a BGP announcement 110 to determine, to a strong level of certainty, that the 111 originating AS in the received PATH attribute possessed the 112 authority to announce the prefix. 114 3.2 A BGPsec design MUST allow the receiver of a BGP announcement 115 to determine, to a strong level of certainty, that the received 116 PATH attribute accurately represents the sequence of eBGP 117 exchanges that propagated the prefix from the origin AS to the 118 receiver, particularly if an AS has added or deleted any AS 119 number other than its own in the path attribute. This includes 120 modification to the number of AS prepends. 122 3.3 BGP attributes other than the AS_PATH are used only locally, or 123 have meaning only between immediate neighbors, may be modified 124 by intermediate systems, and figure less prominently in the 125 decision process. Consequently, it is not appropriate to try 126 to protect such attributes in a BGPsec design. 128 3.4 A BGPsec design MUST be amenable to incremental deployment. 129 This implies that incompatible protocol capabilities MUST be 130 negotiated. 132 3.5 A BGPsec design MUST provide analysis of the operational 133 considerations for deployment and particularly of incremental 134 deployment, e.g, contiguous islands, non-contiguous islands, 135 universal deployment, etc. 137 3.6 As proofs of possession and authentication may require 138 cryptographic payloads and/or storage and computation, likely 139 increasing processing and memory requirements on routers, a 140 BGPsec design MAY require use of new hardware. I.e., 141 compatibility with current hardware abilities is not a 142 requirement that this document imposes on a solution. 144 3.7 A BGPsec design need not prevent attacks on data plane traffic. 145 It need not provide assurance that the data plane even follows 146 the control plane. 148 3.8 A BGPsec design MUST resist attacks by an enemy who has access 149 to the inter-router link layer, per Section 3.1.1.2 of 150 [RFC4593]. In particular, such a design MUST provide 151 mechanisms for authentication of all data, including protecting 152 against message insertion, deletion, modification, or replay. 153 Mechanisms that suffice include TCP sessions authenticated with 154 TCP-AO [RFC5925], IPsec [RFC4301], or TLS [RFC5246]. 156 3.9 It is assumed that a BGPsec design will require information 157 about holdings of address space and ASNs (AS Numbers), and 158 assertions about binding of address space to ASNs. A BGPsec 159 design MAY make use of a security infrastructure (e.g., a PKI) 160 to distribute such authenticated data. 162 3.10 It is entirely OPTIONAL to secure AS SETs and prefix 163 aggregation. The long range solution to this is the 164 deprecation of AS_SETs, see [RFC6472]. 166 3.11 If a BGPsec design uses signed prefixes, given the difficulty 167 of splitting a signed message while preserving the signature, 168 it need not handle multiple prefixes in a single UPDATE PDU. 170 3.12 A BGPsec design MUST enable each BGPsec speaker to configure 171 use of the security mechanism on a per-peer basis. 173 3.13 A BGPsec design MUST provide backward compatibility in the 174 message formatting, transmission, and processing of routing 175 information carried through a mixed security environment. 176 Message formatting in a fully secured environment MAY be 177 handled in a non-backward compatible manner. 179 3.14 While the formal validity of a routing announcement should be 180 determined by the BGPsec protocol, local routing policy MUST be 181 the final arbiter of best path and other routing decisions. 183 3.15 A BGPsec design MUST support 'transparent' route servers, 184 meaning that the AS of the route server is not counted in 185 downstream BGP AS-path-length tie-breaking decisions. 187 3.16 A BGPsec design MUST support AS aliasing. This technique is 188 not well-defined or universally implemented, but is being 189 documented in [I-D.ga-idr-as-migration]. A BGPsec design 190 SHOULD accommodate AS 'migration' techniques such as common 191 proprietary and non-standard methods which allow a router to 192 have two AS identities, without lengthening the effective AS 193 Path. 195 3.17 If a BGPsec design makes use of a security infrastructure, that 196 infrastructure SHOULD enable each network operator to select 197 the entities it will trust when authenticating data in the 198 security infrastructure. See, for example, 199 [I-D.ietf-sidr-lta-use-cases]. 201 3.18 A BGPsec design MUST NOT require operators to reveal more than 202 is currently revealed in the operational inter-domain routing 203 environment, other than the inclusion of necessary security 204 credentials to allow others to ascertain for themselves the 205 necessary degree of assurance regarding the validity of NLRI 206 received via BGPsec. This includes peering, customer/provider 207 relationships, an ISP's internal infrastructure, etc. It is 208 understood that some data are revealed to the savvy seeker by 209 BGP, traceroute, etc. today. 211 3.19 A BGPsec design MUST signal (logging, SNMP, ...) security 212 exceptions which are significant to the operator. The specific 213 data to be signaled are an implementation matter. 215 3.20 Any routing information database MUST be re-authenticated 216 periodically or in an event-driven manner, especially in 217 response to events such as, for example, PKI updates. 219 3.21 Any inter-AS use of cryptographic hashes or signatures, MUST 220 provide mechanisms for algorithm agility. For a discussion, 221 see [I-D.iab-crypto-alg-agility]. 223 3.22 A BGPsec design SHOULD NOT presume to know the intent of the 224 originator of a NLRI, nor that of any AS on the AS Path, other 225 than that they intended to pass it to the next AS in the Path. 227 3.23 A BGPsec listener SHOULD NOT trust non-BGPsec markings, such as 228 communities, across trust boundaries. 230 4. BGP UPDATE Security Requirements 232 The following requirements MUST be met in the processing of BGP 233 UPDATE messages: 235 4.1 A BGPsec design MUST enable each recipient of an UPDATE to 236 formally validate that the origin AS in the message is 237 authorized to originate a route to the prefix(es) in the 238 message. 240 4.2 A BGPsec design MUST enable the recipient of an UPDATE to 241 formally determine that the NLRI has traversed the AS path 242 indicated in the UPDATE. Note that this is more stringent than 243 showing that the path is merely not impossible. 245 4.3 Replay of BGP UPDATE messages need not be completely prevented, 246 but a BGPsec design SHOULD provide a mechanism to control the 247 window of exposure to replay attacks. 249 4.4 A BGPsec design SHOULD provide some level of assurance that the 250 origin of a prefix is still 'alive', i.e., that a monkey in the 251 middle has not withheld a WITHDRAW message or the effects 252 thereof. 254 4.5 The AS Path of an UPDATE message SHOULD be able to be 255 authenticated as the message is processed. 257 4.6 Normal sanity checks of received announcements MUST be done, 258 e.g., verification that the first element of the AS_PATH list 259 corresponds to the locally configured AS of the peer from which 260 the UPDATE was received. 262 4.7 The output of a router applying BGPsec validation to a received 263 UPDATE MUST be unequivocal and conform to a fully specified 264 state in the design. 266 5. IANA Considerations 268 This document asks nothing of the IANA. 270 6. Security Considerations 272 If an external "security infrastructure" is used, as mentioned in 273 Paragraph 9 and Paragraph 17 above, the authenticity and integrity of 274 the data of such an infrastructure MUST be assured. And the 275 integrity of those data MUST be assured when they are used by BGPsec, 276 e.g., in transport. 278 The requirement of backward compatibility to BGP4 may open an avenue 279 to downgrade attacks. 281 The data plane might not follow the path signaled by the control 282 plane. 284 Security for subscriber traffic is outside the scope of this 285 document, and of BGP security in general. IETF standards for payload 286 data security should be employed. While adoption of BGP security 287 measures may ameliorate some classes of attacks on traffic, these 288 measures are not a substitute for use of subscriber-based security. 290 7. Acknowledgments 292 The authors wishe to thank the authors of [I-D.ietf-rpsec-bgpsecrec] 293 from whom we liberally stole, Roque Gagliano, Russ Housley, Geoff 294 Huston, Steve Kent, Sandy Murphy, Eric Osterweil, John Scudder, 295 Kotikalapudi Sriram, Sam Weiler, and a number of others. 297 8. References 299 8.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 305 Routing Protocols", RFC 4593, October 2006. 307 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 308 Authentication Option", RFC 5925, June 2010. 310 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 311 RFC 7132, February 2014. 313 8.2. Informative References 315 [I-D.ga-idr-as-migration] 316 George, W. and S. Amante, "Autonomous System (AS) 317 Migration Features and Their Effects on the BGP AS_PATH 318 Attribute", draft-ga-idr-as-migration-01 (work in 319 progress), February 2013. 321 [I-D.iab-crypto-alg-agility] 322 Housley, R., "Guidelines for Cryptographic Algorithm 323 Agility", draft-iab-crypto-alg-agility-01 (work in 324 progress), June 2014. 326 [I-D.ietf-rpsec-bgpsecrec] 327 Christian, B. and T. Tauber, "BGP Security Requirements", 328 draft-ietf-rpsec-bgpsecrec-10 (work in progress), November 329 2008. 331 [I-D.ietf-sidr-lta-use-cases] 332 Bush, R., "RPKI Local Trust Anchor Use Cases", draft-ietf- 333 sidr-lta-use-cases-00 (work in progress), February 2014. 335 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 336 Protocol 4 (BGP-4)", RFC 4271, January 2006. 338 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 339 Internet Protocol", RFC 4301, December 2005. 341 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 342 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 344 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 345 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 346 December 2011. 348 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 349 Secure Internet Routing", RFC 6480, February 2012. 351 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 352 Resource Certificate Repository Structure", RFC 6481, 353 February 2012. 355 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 356 Origin Authorizations (ROAs)", RFC 6482, February 2012. 358 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 359 Infrastructure (RPKI) to Router Protocol", RFC 6810, 360 January 2013. 362 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 363 Austein, "BGP Prefix Origin Validation", RFC 6811, January 364 2013. 366 Authors' Addresses 368 Steven M. Bellovin 369 Columbia University 370 1214 Amsterdam Avenue, MC 0401 371 New York, New York 10027 372 USA 374 Phone: +1 212 939 7149 375 Email: bellovin@acm.org 376 Randy Bush 377 Internet Initiative Japan 378 5147 Crystal Springs 379 Bainbridge Island, Washington 98110 380 USA 382 Email: randy@psg.com 384 David Ward 385 Cisco Systems 386 170 W. Tasman Drive 387 San Jose, CA 95134 388 USA 390 Email: dward@cisco.com