idnits 2.17.1 draft-ymbk-bgpsec-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 7, 2011) is 4798 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.kent-bgpsec-threats' ** Downref: Normative reference to an Informational RFC: RFC 4593 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-12 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-00 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-pfx-validate-01 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-07 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-10 == Outdated reference: A later version (-26) exists of draft-ietf-sidr-rpki-rtr-10 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 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 8, 2011 Internet Initiative Japan, Inc. 6 D. Ward 7 Juniper Networks 8 March 7, 2011 10 Security Requirements for BGP Path Validation 11 draft-ymbk-bgpsec-reqs-02 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. This document may not be modified, 30 and derivative works of it may not be created, and it may not be 31 published except as an Internet-Draft. 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 September 8, 2011. 45 Copyright Notice 47 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 RPKI-based Origin Validation ([I-D.ietf-sidr-pfx-validate]) provides 77 a measure of resilience to accidental mis-origination of prefixes. 78 But it provides neither cryptographic assurance (announcements are 79 not signed), nor assurance of the AS Path of the announcement. 81 This document describes requirements to be placed on a BGP security 82 protocol, herein termed BGPsec, intended to rectify these gaps. 84 The threat model assumed here is documented in [RFC4593] and 85 [I-D.kent-bgpsec-threats]. 87 2. Recommended Reading 89 This document assumes knowledge of the RPKI see [I-D.ietf-sidr-arch] 90 and the RPKI Repository Structure, see [I-D.ietf-sidr-repos-struct]. 92 This document assumes ongoing incremental deployment of ROAs, see 93 [I-D.ietf-sidr-roa-format], the RPKI to Router Protocol, see 94 [I-D.ietf-sidr-rpki-rtr], and RPKI-based Prefix Validation, see 95 [I-D.ietf-sidr-pfx-validate]. 97 And, of course, a knowledge of BGP [RFC4271] is required. 99 3. General Requirements 101 The following are general requirements for a BGPsec protocol: 103 3.1 A BGPsec design must allow the receiver of a BGP announcement 104 to determine, to a strong level of certainty, that the received 105 PATH attribute accurately represents the sequence of eBGP 106 exchanges that propagated the prefix from the origin AS to the 107 receiver. 109 3.2 A BGPsec design MUST be amenable to incremental deployment. 110 Any incompatible protocol capabilities MUST be negotiated. 112 3.3 A BGPsec design MUST provide analysis of the operational 113 considerations for deployment and particularly of incremental 114 deployment, e.g, contiguous islands, non-contiguous islands, 115 universal deployment, etc.. 117 3.4 As cryptographic payloads and memory requirements on routers 118 are likely to increase, a BGPsec design MAY require use of new 119 hardware. I.e. compatibility with current hardware abilities 120 is not a requirement that this document imposes on a solution. 121 As BGPsec will likely not be rolled out for some years, this 122 should not be a major problem. 124 3.5 A BGPsec design need not prevent attacks on data plane traffic. 125 It need not provide assurance that the data plane even follows 126 the control plane. 128 3.6 A BGPsec design MUST resist attacks by an enemy who has access 129 to the link layer, per Section 3.1.1.2 of [RFC4593]. In 130 particular, such a design must provide mechanisms for 131 authentication of all data, including protecting against 132 message insertion, deletion, modification, or replay. 133 Mechanisms that suffice include TCP sessions authenticated with 134 IPsec [RFC4301] or TLS [RFC5246]. 136 3.7 A BGPsec design MAY make use of a security infrastructure 137 (e.g., a PKI) to distribute authenticated data used as input to 138 routing decisions. Such data include information about 139 holdings of address space and ASNs, and assertions about 140 binding of address space to ASNs. 142 3.8 If message signing increases message size, the 4096 byte limit 143 on BGP PDU size MAY be removed. 145 3.9 It is entirely OPTIONAL to secure AS SETs and prefix 146 aggregation. The long range solution to this is the 147 deprecation of AS-SETs, see [I-D.wkumari-deprecate-as-sets]. 149 3.10 If a BGPsec design uses signed prefixes, given the difficulty 150 of splitting a signed message while preserving the signature, 151 it need NOT handle multiple prefixes in a single UPDATE PDU. 153 3.11 A BGPsec design MUST enable each BGPsec speaker to configure 154 use of the security mechanism on a per-peer basis. 156 3.12 A BGPsec design MUST provide backward compatibility in the 157 message formatting, transmission, and processing of routing 158 information carried through a mixed security environment. 159 Message formatting in a fully secured environment MAY be 160 handled in a non-backward compatible manner. 162 3.13 While the trust level of an NLRI should be determined by the 163 BGPsec protocol, local routing preference and policy MUST then 164 be applied to best path and other decisions. Such mechanisms 165 MUST conform with [I-D.ietf-sidr-ltamgmt]. 167 3.14 If a BGPsec design makes use of a security infrastructure, that 168 infrastructure SHOULD enable each network operator to select 169 the entities it will trust when authenticating data in the 170 security infrastructure. See, for example, 171 [I-D.ietf-sidr-ltamgmt]. 173 3.15 A BGPsec design MUST NOT require operators to reveal more than 174 is currently revealed in the operational inter-domain routing 175 environment, other than the inclusion of necessary security 176 credentials to allow others to ascertain for themselves the 177 necessary degree of assurance regarding the validity of NLRI 178 received via BGPsec. This includes peering, customer, and 179 provider relationships, an ISP's internal infrastructure, etc. 180 It is understood that some data are revealed to the savvy 181 seeker by BGP, traceroute, etc. today. 183 3.16 A BGPsec design SHOULD flag security exceptions which are 184 significant enough to be logged. The specific data to be 185 logged are an implementation matter. 187 3.17 Any routing information database MAY be re-authenticated 188 periodically or in an event-driven manner, especially in 189 response to events such as, for example, PKI updates. 191 3.18 Should a BGPsec design use hashes or signatures, it should 192 provide mechanisms for algorithm agility. 194 3.19 A BGPsec design SHOULD NOT presume to know the intent of the 195 originator of a NLRI, nor that of any AS on the AS Path. 197 3.20 A BGP listener SHOULD NOT trust non-BGPsec markings, such as 198 communities, across trust boundaries. 200 4. BGP UPDATE Security Requirements 202 The following requirements MUST be met in the processing of BGP 203 UPDATE messages: 205 4.1 A BGPsec design MUST enable each recipient of an UPDATE to 206 formally validate that the origin AS in the message is 207 authorized to originate a route to the prefix(es) in the 208 message. 210 4.2 A BGPsec design MUST enable the recipient of an UPDATE to 211 formally determine that the NLRI has traversed the AS path 212 indicated in the UPDATE. Note that this is more stringent than 213 showing that the path is merely not impossible. 215 4.3 Replay of BGP UPDATE messages need not be completely prevented, 216 but a BGPsec design MUST provide a mechanism to control the 217 window of exposure to replay attacks. 219 4.4 A BGPsec design SHOULD provide some level of assurance that the 220 origin of a prefix is still 'alive', i.e. that a monkey in the 221 middle has not withheld a WITHDRAW message or the effects 222 thereof. 224 4.5 NLRI of the UPDATE message SHOULD be able to be authenticated in 225 real-time as the message is processed. 227 4.6 Normal sanity checks of received announcements MUST be done, 228 e.g. verification that the first element of the AS_PATH list 229 corresponds to the locally configured AS of the peer from which 230 the UPDATE was received. 232 4.7 The output of a router applying BGPsec to a received signed 233 UPDATE MUST be either Valid or Unverified. There should be no 234 shades of grey. 236 5. IANA Considerations 238 This document asks nothing of the IANA. 240 6. Security Considerations 242 The data plane may not follow the control plane. 244 Security for subscriber traffic is outside the scope of this 245 document, and of BGP security in general. IETF standards for payload 246 data security should be employed. While adoption of BGP security 247 measures may ameliorate some classes of attacks on traffic, these 248 measures are not a substitute for use of subscriber-based security. 250 7. Acknowledgments 252 The author wishes to thank the authors of [I-D.ietf-rpsec-bgpsecrec] 253 from whom we liberally stole, Russ Housley, Geoff Huston, Steve Kent, 254 Sandy Murphy, John Scudder, Sam Weiler, and a number of others. 256 8. References 258 8.1. Normative References 260 [I-D.kent-bgpsec-threats] 261 Kent, S., "Threat Model for BGP Path Security", 262 draft-kent-bgpsec-threats-01 (work in progress), 263 February 2011. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 269 Routing Protocols", RFC 4593, October 2006. 271 8.2. Informative References 273 [I-D.ietf-rpsec-bgpsecrec] 274 Christian, B. and T. Tauber, "BGP Security Requirements", 275 draft-ietf-rpsec-bgpsecrec-10 (work in progress), 276 November 2008. 278 [I-D.ietf-sidr-arch] 279 Lepinski, M. and S. Kent, "An Infrastructure to Support 280 Secure Internet Routing", draft-ietf-sidr-arch-12 (work in 281 progress), February 2011. 283 [I-D.ietf-sidr-ltamgmt] 284 Kent, S. and M. Reynolds, "Local Trust Anchor Management 285 for the Resource Public Key Infrastructure", 286 draft-ietf-sidr-ltamgmt-00 (work in progress), 287 November 2010. 289 [I-D.ietf-sidr-pfx-validate] 290 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 291 Austein, "BGP Prefix Origin Validation", 292 draft-ietf-sidr-pfx-validate-01 (work in progress), 293 February 2011. 295 [I-D.ietf-sidr-repos-struct] 296 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 297 Resource Certificate Repository Structure", 298 draft-ietf-sidr-repos-struct-07 (work in progress), 299 February 2011. 301 [I-D.ietf-sidr-roa-format] 302 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 303 Origin Authorizations (ROAs)", 304 draft-ietf-sidr-roa-format-10 (work in progress), 305 February 2011. 307 [I-D.ietf-sidr-rpki-rtr] 308 Bush, R. and R. Austein, "The RPKI/Router Protocol", 309 draft-ietf-sidr-rpki-rtr-10 (work in progress), 310 March 2011. 312 [I-D.wkumari-deprecate-as-sets] 313 Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.", 314 draft-wkumari-deprecate-as-sets-01 (work in progress), 315 September 2010. 317 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 318 Protocol 4 (BGP-4)", RFC 4271, January 2006. 320 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 321 Internet Protocol", RFC 4301, December 2005. 323 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 324 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 326 Authors' Addresses 328 Steven M. Bellovin 329 Columbia University 330 1214 Amsterdam Avenue, MC 0401 331 New York, New York 10027 332 US 334 Phone: +1 212 939 7149 335 Email: bellovin@acm.org 337 Randy Bush 338 Internet Initiative Japan, Inc. 339 5147 Crystal Springs 340 Bainbridge Island, Washington 98110 341 US 343 Phone: +1 206 780 0431 x1 344 Email: randy@psg.com 345 Dave Ward 346 Juniper Networks 347 1194 N. Mathilda Ave. 348 Sunnyvale, California 94089-1206 349 US 351 Phone: +1-408-745-2000 352 Email: dward@juniper.net