idnits 2.17.1 draft-ietf-sidr-bgpsec-reqs-03.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 date (March 11, 2012) is 4429 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-sidr-bgpsec-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-bgpsec-threats (ref. 'I-D.ietf-sidr-bgpsec-threats') ** Downref: Normative reference to an Informational RFC: RFC 4593 == Outdated reference: A later version (-36) exists of draft-ietf-idr-bgp-extended-messages-02 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-04 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-pfx-validate-03 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 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: Standards Track R. Bush 5 Expires: September 12, 2012 Internet Initiative Japan 6 D. Ward 7 Cisco Systems 8 March 11, 2012 10 Security Requirements for BGP Path Validation 11 draft-ietf-sidr-bgpsec-reqs-03 13 Abstract 15 This document describes requirements for a future BGP security 16 protocol design to provide cryptographic assurance that the origin AS 17 had the right to announce the prefix and to provide assurance of the 18 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" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Recommended Reading . . . . . . . . . . . . . . . . . . . . . . 3 62 3. General Requirements . . . . . . . . . . . . . . . . . . . . . 3 63 4. BGP UPDATE Security Requirements . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 RPKI-based Origin Validation ([I-D.ietf-sidr-pfx-validate]) provides 75 a measure of resilience to accidental mis-origination of prefixes. 76 But it provides neither cryptographic assurance (announcements are 77 not signed), nor assurance of the AS Path of the announcement. 79 This document describes requirements to be placed on a BGP security 80 protocol, herein termed BGPsec, intended to rectify these gaps. 82 The threat model assumed here is documented in [RFC4593] and 83 [I-D.ietf-sidr-bgpsec-threats]. 85 As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this 86 work is limited to threats to the BGP protocol. Issues of business 87 relationship confomance, of which routing 'leaks' are a subset, while 88 important are outside the scope of the working group and therefore 89 this document. It is hoped that these issues will be better 90 understood in the future. 92 2. Recommended Reading 94 This document assumes knowledge of the RPKI see [RFC6480], the RPKI 95 Repository Structure, see [RFC6481]. 97 This document assumes ongoing incremental deployment of ROAs, see 98 [RFC6482], the RPKI to Router Protocol, see [I-D.ietf-sidr-rpki-rtr], 99 and RPKI-based Prefix Validation, see [I-D.ietf-sidr-pfx-validate]. 101 And, of course, a knowledge of BGP [RFC4271] is required. 103 3. General Requirements 105 The following are general requirements for a BGPsec protocol: 107 3.1 A BGPsec design must allow the receiver of a BGP announcement 108 to determine, to a strong level of certainty, that the received 109 PATH attribute accurately represents the sequence of eBGP 110 exchanges that propagated the prefix from the origin AS to the 111 receiver. 113 3.2 A BGPsec design must allow the receiver of an announcement to 114 detect if an AS has added or deleted any AS number other than 115 its own in the path attribute. This includes modification to 116 the number of AS prepends. 118 3.3 A BGPsec design MUST be amenable to incremental deployment. 119 Any incompatible protocol capabilities MUST be negotiated. 121 3.4 A BGPsec design MUST provide analysis of the operational 122 considerations for deployment and particularly of incremental 123 deployment, e.g, contiguous islands, non-contiguous islands, 124 universal deployment, etc.. 126 3.5 As cryptographic payloads and memory requirements on routers 127 are likely to increase, a BGPsec design MAY require use of new 128 hardware. I.e. compatibility with current hardware abilities 129 is not a requirement that this document imposes on a solution. 130 As BGPsec will likely not be rolled out for some years, this 131 should not be a major problem. 133 3.6 A BGPsec design need not prevent attacks on data plane traffic. 134 It need not provide assurance that the data plane even follows 135 the control plane. 137 3.7 A BGPsec design MUST resist attacks by an enemy who has access 138 to the inter-router link layer, per Section 3.1.1.2 of 139 [RFC4593]. In particular, such a design must provide 140 mechanisms for authentication of all data, including protecting 141 against message insertion, deletion, modification, or replay. 142 Mechanisms that suffice include TCP sessions authenticated with 143 TCP-AO [RFC5925], IPsec [RFC4301], or TLS [RFC5246]. 145 3.8 It is assumed that a BGPsec design will require information 146 about holdings of address space and ASNs, and assertions about 147 binding of address space to ASNs. A BGPsec design MAY make use 148 of a security infrastructure (e.g., a PKI) to distribute such 149 authenticated data. 151 3.9 [ this point should probably be removed. it remains to keep 152 numbering for the moment ] If message signing increases message 153 size, the 4096 byte limit on BGP PDU size MAY be removed, see 154 [I-D.ietf-idr-bgp-extended-messages]. 156 3.10 It is entirely OPTIONAL to secure AS SETs and prefix 157 aggregation. The long range solution to this is the 158 deprecation of AS-SETs, see [I-D.ietf-idr-deprecate-as-sets]. 160 3.11 If a BGPsec design uses signed prefixes, given the difficulty 161 of splitting a signed message while preserving the signature, 162 it need NOT handle multiple prefixes in a single UPDATE PDU. 164 3.12 A BGPsec design MUST enable each BGPsec speaker to configure 165 use of the security mechanism on a per-peer basis. 167 3.13 A BGPsec design MUST provide backward compatibility in the 168 message formatting, transmission, and processing of routing 169 information carried through a mixed security environment. 170 Message formatting in a fully secured environment MAY be 171 handled in a non-backward compatible manner. 173 3.14 While the trust level of an NLRI should be determined by the 174 BGPsec protocol, local routing preference and policy MUST then 175 be applied to best path and other decisions. Such mechanisms 176 MUST conform with [I-D.ietf-sidr-ltamgmt]. 178 3.15 A BGPsec design MUST support 'transparent' route servers, 179 meaning that the AS of the route server is not counted in 180 downstream BGP AS-path-length tie-breaking decisions. 182 3.16 If a BGPsec design makes use of a security infrastructure, that 183 infrastructure SHOULD enable each network operator to select 184 the entities it will trust when authenticating data in the 185 security infrastructure. See, for example, 186 [I-D.ietf-sidr-ltamgmt]. 188 3.17 A BGPsec design MUST NOT require operators to reveal more than 189 is currently revealed in the operational inter-domain routing 190 environment, other than the inclusion of necessary security 191 credentials to allow others to ascertain for themselves the 192 necessary degree of assurance regarding the validity of NLRI 193 received via BGPsec. This includes peering, customer, and 194 provider relationships, an ISP's internal infrastructure, etc. 195 It is understood that some data are revealed to the savvy 196 seeker by BGP, traceroute, etc. today. 198 3.18 A BGPsec design SHOULD flag security exceptions which are 199 significant enough to be logged. The specific data to be 200 logged are an implementation matter. 202 3.19 Any routing information database MUST be re-authenticated 203 periodically or in an event-driven manner, especially in 204 response to events such as, for example, PKI updates. 206 3.20 Any inter-AS use of cryptographic hashes or signatures, MUST 207 provide mechanisms for algorithm agility. 209 3.21 A BGPsec design SHOULD NOT presume to know the intent of the 210 originator of a NLRI, nor that of any AS on the AS Path. 212 3.22 A BGP listener SHOULD NOT trust non-BGPsec markings, such as 213 communities, across trust boundaries. 215 4. BGP UPDATE Security Requirements 217 The following requirements MUST be met in the processing of BGP 218 UPDATE messages: 220 4.1 A BGPsec design MUST enable each recipient of an UPDATE to 221 formally validate that the origin AS in the message is 222 authorized to originate a route to the prefix(es) in the 223 message. 225 4.2 A BGPsec design MUST enable the recipient of an UPDATE to 226 formally determine that the NLRI has traversed the AS path 227 indicated in the UPDATE. Note that this is more stringent than 228 showing that the path is merely not impossible. 230 4.3 Replay of BGP UPDATE messages need not be completely prevented, 231 but a BGPsec design MUST provide a mechanism to control the 232 window of exposure to replay attacks. 234 4.4 A BGPsec design SHOULD provide some level of assurance that the 235 origin of a prefix is still 'alive', i.e. that a monkey in the 236 middle has not withheld a WITHDRAW message or the effects 237 thereof. 239 4.5 NLRI of the UPDATE message SHOULD be able to be authenticated as 240 the message is processed. 242 4.6 Normal sanity checks of received announcements MUST be done, 243 e.g. verification that the first element of the AS_PATH list 244 corresponds to the locally configured AS of the peer from which 245 the UPDATE was received. 247 4.7 The output of a router applying BGPsec to a received signed 248 UPDATE MUST be either unequivocal and conform to a fully 249 specified state in the design. 251 5. IANA Considerations 253 This document asks nothing of the IANA. 255 6. Security Considerations 257 The data plane may not follow the control plane. 259 Security for subscriber traffic is outside the scope of this 260 document, and of BGP security in general. IETF standards for payload 261 data security should be employed. While adoption of BGP security 262 measures may ameliorate some classes of attacks on traffic, these 263 measures are not a substitute for use of subscriber-based security. 265 7. Acknowledgments 267 The author wishes to thank the authors of [I-D.ietf-rpsec-bgpsecrec] 268 from whom we liberally stole, Russ Housley, Geoff Huston, Steve Kent, 269 Sandy Murphy, John Scudder, Sam Weiler, and a number of others. 271 8. References 273 8.1. Normative References 275 [I-D.ietf-sidr-bgpsec-threats] 276 Kent, S. and A. Chi, "Threat Model for BGP Path Security", 277 draft-ietf-sidr-bgpsec-threats-02 (work in progress), 278 February 2012. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 284 Routing Protocols", RFC 4593, October 2006. 286 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 287 Authentication Option", RFC 5925, June 2010. 289 8.2. Informative References 291 [I-D.ietf-idr-bgp-extended-messages] 292 Patel, K. and R. Bush, "Extended Message support for BGP", 293 draft-ietf-idr-bgp-extended-messages-02 (work in 294 progress), January 2012. 296 [I-D.ietf-idr-deprecate-as-sets] 297 Kumari, W. and K. Sriram, "Recommendation for Not Using 298 AS_SET and AS_CONFED_SET in BGP", 299 draft-ietf-idr-deprecate-as-sets-06 (work in progress), 300 October 2011. 302 [I-D.ietf-rpsec-bgpsecrec] 303 Christian, B. and T. Tauber, "BGP Security Requirements", 304 draft-ietf-rpsec-bgpsecrec-10 (work in progress), 305 November 2008. 307 [I-D.ietf-sidr-ltamgmt] 308 Reynolds, M. and S. Kent, "Local Trust Anchor Management 309 for the Resource Public Key Infrastructure", 310 draft-ietf-sidr-ltamgmt-04 (work in progress), 311 December 2011. 313 [I-D.ietf-sidr-pfx-validate] 314 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 315 Austein, "BGP Prefix Origin Validation", 316 draft-ietf-sidr-pfx-validate-03 (work in progress), 317 October 2011. 319 [I-D.ietf-sidr-rpki-rtr] 320 Bush, R. and R. Austein, "The RPKI/Router Protocol", 321 draft-ietf-sidr-rpki-rtr-26 (work in progress), 322 February 2012. 324 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 325 Protocol 4 (BGP-4)", RFC 4271, January 2006. 327 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 328 Internet Protocol", RFC 4301, December 2005. 330 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 331 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 333 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 334 Secure Internet Routing", RFC 6480, February 2012. 336 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 337 Resource Certificate Repository Structure", RFC 6481, 338 February 2012. 340 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 341 Origin Authorizations (ROAs)", RFC 6482, February 2012. 343 Authors' Addresses 345 Steven M. Bellovin 346 Columbia University 347 1214 Amsterdam Avenue, MC 0401 348 New York, New York 10027 349 US 351 Phone: +1 212 939 7149 352 Email: bellovin@acm.org 354 Randy Bush 355 Internet Initiative Japan 356 5147 Crystal Springs 357 Bainbridge Island, Washington 98110 358 US 360 Phone: +1 206 780 0431 x1 361 Email: randy@psg.com 363 David Ward 364 Cisco Systems 365 170 W. Tasman Drive 366 San Jose, CA 95134 367 USA 369 Email: dward@cisco.com