idnits 2.17.1 draft-ietf-grow-rpki-as-cones-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6480], [RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2019) is 1880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations J. Snijders 3 Internet-Draft NTT 4 Intended status: Informational M. Stucchi 5 Expires: September 6, 2019 RIPE NCC 6 March 5, 2019 8 RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous 9 Systems Numbers To Facilitate BGP Filtering 10 draft-ietf-grow-rpki-as-cones-01 12 Abstract 14 This document describes a way to define groups of Autonomous System 15 numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide 16 a mechanism to be used by operators for filtering BGP-4 [RFC4271] 17 announcements. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in BCP 24 14 [RFC2119] [RFC8174] when, and only when, they appear in all 25 capitals, as shown here. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 6, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Format of AS-Cone objects . . . . . . . . . . . . . . . . . . 3 63 2.1. Policy definition object . . . . . . . . . . . . . . . . 3 64 2.1.1. Naming convention for Policy definition objects . . . 3 65 2.1.2. ASN.1 format of a Policy Definition object . . . . . 3 66 2.1.3. Naming convention for neighbour relationships . . . . 4 67 2.2. AS-Cone definition object . . . . . . . . . . . . . . . . 4 68 2.2.1. Naming convention for AS-Cone objects . . . . . . . . 4 69 2.2.2. ASN.1 format of an AS-Cone . . . . . . . . . . . . . 5 70 3. Validating an AS-Cone . . . . . . . . . . . . . . . . . . . . 5 71 4. Recommendations for use of AS-Cones at Internet Exchange 72 points . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Publication of AS-Cones as IRR objects . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 10.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 The main goal of the Resource Public Key Infrastructure (RPKI) system 86 [RFC6480] is to support improved security for the global routing 87 system. This is achieved through the use of information stored in a 88 distributed repository system comprised of signed objects. A 89 commonly used object type is the Route Object Authorisation (ROAs), 90 which describe the prefixes originated by ASNs. 92 There is however no way for an operator to assert the routes for its 93 customer networks, making it difficult to use the information carried 94 by RPKI to create meaningful BGP-4 filters without relying on RPSL 95 [RFC2622] as-sets. 97 This memo introduces a new attestation object, called an AS-Cone. An 98 AS-Cone is a digitally signed object with the goal to enable 99 operators to define a set of customers that can be found as "right 100 adjacencies", or transit customer networks, facilitating the 101 construction of prefix filters for a given ASN, thus making routing 102 more secure. 104 2. Format of AS-Cone objects 106 AS-Cones are composed of two types of distinct objects: 108 o Policy definitions; and 110 o The AS-Cones themselves. 112 These objects are stored in ASN.1 format and are digitally signed 113 according to the same rules and conventions applied for RPKI ROA 114 Objects ([RFC6482]). 116 2.1. Policy definition object 118 A policy definition contains a list the upstream and peering 119 relationships for a given Autonomous System that need an AS-Cone to 120 be used for filtering. For each relationship, an AS-Cone is 121 referenced to indicate which BGP networks will be announced to the 122 other end of the relationship. 124 The default behaviour for a neighbour, if the relationship is not 125 explicitly described in the policy, is to only accept the networks 126 originated by the ASN. This means that a stub ASN neither has to set 127 up any AS-Cone, description, nor policy. 129 Only one AS-Cone can be supplied for a given relationship. If more 130 than one AS-Cone needs to be announced in the relationship, then it 131 is mandatory to create a third AS-Cone that includes those two. 133 2.1.1. Naming convention for Policy definition objects 135 A Policy object is referenced using the Autonomous System number it 136 refers to, preceded by the string "AS". 138 2.1.2. ASN.1 format of a Policy Definition object 139 ASNPolicy DEFINITIONS ::= 140 BEGIN 141 Neighbours ::= SEQUENCE OF Neighbour 143 Neighbour ::= SEQUENCE 144 { 145 ASN INTEGER (1..42949672965), 146 ASCone VisibleString 147 } 149 Version ::= INTEGER 150 LastModified ::= GeneralizedTime 151 Created ::= GeneralizedTime 152 END 154 ASN.1 format of a Policy definition object 156 2.1.3. Naming convention for neighbour relationships 158 When referring to a neighbour relationship contained in a Policy 159 definition object the following convention should be used: 161 ASX:ASY 163 Where X is the number of the AS holder and Y is the number of the ASN 164 intended to use the AS-Cone object to generate a filter. 166 2.2. AS-Cone definition object 168 An AS-Cone contains a list of the downstream customers and AS-Cones 169 of a given ASN. The list is used to create filter lists by the 170 networks providing transit or a peering relationship with the ASN. 172 An AS-Cone can reference another AS-Cone if a customer of the 173 operator also has defined an AS-Cone to be announced upstream. 175 2.2.1. Naming convention for AS-Cone objects 177 AS-Cones MUST have a unique name for the ASN they belong to. Names 178 are composed of ASCII strings up to 255 characters long and cannot 179 contain spaces. 181 In order for AS-Cones to be unique in the global routing system, 182 their string name is preceded by the AS number of the ASN they are 183 part of, followed by ":". For example, AS-Cone "EuropeanCustomers" 184 for ASN 65530 is represented as "AS65530:EuropeanCustomers" when 185 referenced from a third party. 187 2.2.2. ASN.1 format of an AS-Cone 189 ASCone DEFINITIONS ::= 190 BEGIN 191 Entities ::= SEQUENCE OF Entity 193 Entity CHOICE 194 { 195 ASN INTEGER (1..4294967295), 196 OtherASCone VisibleString 197 } 199 Version ::= INTEGER 200 LastModified ::= GeneralizedTime 201 Created ::= GeneralizedTime 202 END 204 ASN.1 format of an AS-Cone 206 3. Validating an AS-Cone 208 The goal of AS-Cones is to be able to recursively define all the 209 originating ASNs that define the customer base of a given ASN, 210 including all the transit relationships. This means that through AS- 211 Cones, it is possible to create a graph of all the neighbour 212 relationships for the customers of a given ASN. 214 In order to validate a full AS-Cone, a network operator MUST have 215 access to the validated cache of an RPKI validator software 216 containing all the Policy definition and AS-Cone objects. Validation 217 occurs following the description in: [RFC6488]. 219 In order to validate a full AS-Cone, an operator SHOULD perform the 220 following steps: 222 1. For Every downstream ASN, the operator takes its policy 223 definition file and collects a list of ASNs for the cone by 224 looking at the following data, in exact order: 226 1. A policy for the specific relationship, in the form of 227 ASX:ASY, where ASX is the downstream ASN, and ASY is the ASN 228 of the operator validating the AS-Cone; 230 2. If there is no specific definition for the relationship, the 231 ASX:Default policy; 233 If none of the two objects above exists, then the operator should 234 only consider the ASN of its downstream to be added to the list. 236 2. These objects can either point to: 238 1. An AS-Cone; or 240 2. An ASN 242 3. If the definition points to an AS-Cone, the operator looks for 243 the object referenced, which should be contained in the validated 244 cache; 246 4. If the validated cache does not contain the referenced object, 247 then the validation moves on to the next downstream ASN; 249 5. If the validated cache contains the referenced object, the 250 validation process evaluates every entry in the AS-Cone. For 251 each entry: 253 1. If there is a reference to an ASN, then the operator adds the 254 ASN to the list for the given AS-Cone; 256 2. If there is a reference to another AS-Cone, the validating 257 process should recursively process all the entries in that 258 AS-Cone first, with the same principles contained in this 259 list. 261 Since the goal is to build a list of ASNs announcing routes in 262 the AS-Cone, then if an ASN or an AS-Cone are referenced more 263 than once in the process, their contents should only be added 264 once to the list. This is intended to avoid endless loops, and 265 in order to avoid cross-reference of AS-Cones. 267 6. When all the AS-Cones referenced in the policies have been 268 recursively iterated, and all the originating ASNs have been 269 taken into account, the operator can then build a full prefix- 270 list with all the prefixes originated in its AS-Cone. This can 271 be done by querying the RPKI validator software for all the 272 networks originated by every ASN referenced in the AS-Cone. 274 4. Recommendations for use of AS-Cones at Internet Exchange points 276 When an operator is a member of an internet exchange point, it is 277 recommended for it to create at least a Default policy. 279 In case of a peering session with a route server, the operator could 280 publish a policy pointing to the ASN of the route server. A route 281 server operator, then, could build strict prefix filtering rules for 282 all the participants, and offer it as a service to its members. 284 5. Publication of AS-Cones as IRR objects 286 AS-Cones are very similar to AS-Set RPSL Objects, so they could also 287 be published in IRR Databases as AS-Set objects. Every ASN contained 288 in an AS-Cone, and all the AS-Cones referenced should be considered 289 as member: attributes. The naming convention for AS-Cones (ASX:AS- 290 Cone) should be maintained, in order to keep consistency between the 291 two databases. 293 6. Security Considerations 295 TBW 297 7. IANA Considerations 299 This memo includes no request to IANA. 301 8. Contributors 303 The following people contributed significantly to the content of the 304 document: Greg Skinner. 306 9. Acknowledgments 308 The authors would like to thank ... 310 10. References 312 10.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 320 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 321 DOI 10.17487/RFC4271, January 2006, 322 . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 10.2. Informative References 330 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 331 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 332 "Routing Policy Specification Language (RPSL)", RFC 2622, 333 DOI 10.17487/RFC2622, June 1999, 334 . 336 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 337 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 338 February 2012, . 340 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 341 Origin Authorizations (ROAs)", RFC 6482, 342 DOI 10.17487/RFC6482, February 2012, 343 . 345 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 346 Template for the Resource Public Key Infrastructure 347 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 348 . 350 Authors' Addresses 352 Job Snijders 353 NTT Communications 354 Theodorus Majofskistraat 100 355 Amsterdam 1065 SZ 356 The Netherlands 358 Email: job@ntt.net 360 Massimiliano Stucchi 361 RIPE NCC 362 Stationsplein, 11 363 Amsterdam 1012 AB 364 The Netherlands 366 Email: mstucchi@ripe.net