idnits 2.17.1 draft-ietf-grow-irr-routing-policy-considerations-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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-grow-irr-routing-policy-considerations-02', but the file name used is 'draft-ietf-grow-irr-routing-policy-considerations-03' 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 (April 30, 2014) is 3621 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW Working Group D. McPherson 3 Internet-Draft Verisign, Inc. 4 Intended status: Standards Track S. Amante 5 Expires: November 1, 2014 Level 3 Communications 6 E. Osterweil 7 Verisign, Inc. 8 L. Blunk 9 Merit Network, Inc. 10 D. Mitchell 11 Twitter, Inc. 12 April 30, 2014 14 IRR & Routing Policy Configuration Considerations 15 17 Abstract 19 The purpose of this document is to catalog past issues influencing 20 the efficacy of Internet Routing Registries (IRR) for inter-domain 21 routing policy specification and application in the global routing 22 system over the past two decades. Additionally, it provides a 23 discussion regarding which of these issues are still problematic in 24 practice, and which are simply artifacts that are no longer 25 applicable but continue to stifle inter-provider policy-based 26 filtering adoption and IRR utility to this day. 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 November 1, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3 68 4. Accuracy and Integrity of Data Contained within the IRR . . . 4 69 4.1. Lack of Resource Certification . . . . . . . . . . . . . . 4 70 4.2. Incentives to Maintain Data within the IRR . . . . . . . . 5 71 4.3. Inability for Third Parties to Remove (Stale) 72 Information from the IRRs . . . . . . . . . . . . . . . . 6 73 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7 74 4.5. Conclusions with respect to Data in the IRR . . . . . . . 8 76 5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8 77 5.1. Replication of Resources Among IRRs . . . . . . . . . . . 8 78 5.2. Updating Routing Policies from Updated IRR Resources . . . 9 80 6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11 82 7. Historical Limitations of Routers . . . . . . . . . . . . . . 12 83 7.1. Incremental Updates to Policy on Routers . . . . . . . . . 12 84 7.2. Storage Requirements for Policy on Routers . . . . . . . . 13 85 7.3. Updating Configuration on Routers . . . . . . . . . . . . 13 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 93 11. Informative References . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The purpose of this document is to catalog past issues influencing 100 the efficacy of Internet Routing Registries (IRR) for inter-domain 101 routing policy specification and application in the global routing 102 system over the past two decades. Additionally, it provides a 103 discussion regarding which of these issues still pose problems in 104 practice, and which are no longer obstacles, but whose perceived 105 drawbacks continue to stifle inter-provider policy-based filtering 106 support and IRR utility to this day. 108 2. Background 110 IRRs can be used to express a multitude of Internet number bindings 111 and policy objectives, to include bindings between an origin AS and a 112 given prefix, AS and community import and export policies for a given 113 AS, as well as AS macros (as-sets in RPSL-speak) that convey the set 114 of ASes for which a given AS intends to include in some common group. 116 As quoted from Section 7 of [RFC1787], Routing in a Multi-Provider 117 Internet: 119 While ensuring Internet-wide coordination may be more and more 120 difficult, as the Internet continues to grow, stability and 121 consistency of the Internet-wide routing could significantly 122 benefit if the information about routing requirements of various 123 organizations could be shared across organizational boundaries. 124 Such information could be used in a wide variety of situations 125 ranging from troubleshooting to detecting and eliminating 126 conflicting routing requirements. The scale of the Internet 127 implies that the information should be distributed. Work is 128 currently underway to establish depositories of this information 129 (Routing Registries), as well as to develop tools that analyze, as 130 well as utilize this information. 132 3. Historical Artifacts Influencing IRR Efficacy 134 The term IRR is often used, incorrectly, as a broad catch-all term to 135 categorize issues related to the accuracy of data in the IRR, the 136 Routing Policy Specification Language (RPSL) and the operational 137 deployment of policy (derived from RPSL contained within the IRR) to 138 routers. It is important to classify these issues into distinct 139 categories so that the reader can understand which categories of 140 issues are historical artifacts that are no longer applicable and 141 which categories of issues still exist and might be addressed by the 142 IETF. 144 The following sections will separate out challenges related to the 145 IRR into the following categories. First, accuracy and integrity of 146 data contained within the IRR. Second, the Resource Policy 147 Specification Language (RPSL) used to represent various types of data 148 in the IRR. Third, operation of the IRR infrastructure, i.e.: 149 synchronization of resources from one IRR to other IRRs. Finally, 150 the methods related to extraction of policy from the IRR and the 151 input plus activation of that policy within routers. 153 4. Accuracy and Integrity of Data Contained within the IRR 155 The following section will examine issues related to accuracy and 156 integrity of data contained within the IRR. 158 4.1. Lack of Resource Certification 160 Internet number resources include IPv4 addresses, IPv6 addresses, 161 Autonomous System Numbers (ASNs), and more. While these resources 162 are generally allocated by hierarchical authorities, a general 163 mechanism for formally verifying (such as through cryptographic 164 mechanisms) when parties have been allocated resource remains an open 165 challenge. We generally define such a system a Resource 166 Certification System, and we note that some candidate examples of how 167 such a general system might be implemented and deployed exist 168 [RC_HotNetsX], [RFC6480]. 170 One of the largest weaknesses often cited with the IRR system is that 171 the data contained within the IRRs is out of date or lacks integrity. 172 This is largely attributable to the fact that existing IRR mechanisms 173 do not provide ways for a relying party to (cryptographically) verify 174 the validity of an IRR object. That is, there has never existed a 175 resource certification infrastructure that enables a resource holder 176 to authorize a particular autonomous system to originate network 177 layer reachability advertisements for a given IPv4 or IPv6 prefix. 178 It should be noted that this is not a weakness of the underlying 179 Routing Policy Specification Language (RPSL) [RFC2622], but rather, 180 was largely the result of no clear demand by the operator community 181 for Internet Number Resource Registries to provide sufficient 182 resource certification infrastructure that would enable a resource 183 holder to develop a cryptographic binding between, for example, a 184 given AS number and an IP prefix. 186 Another noteworthy (but slightly different) deficiency in the IRR 187 system is the absence of a tangible tie between the resource and the 188 resource holder. That is, generally there is no assurance of the 189 validity of objects at their creation time (except for a subset of, 190 for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE 191 address holders and RIPE ASN holders). If a resource holder's 192 authorization cannot be certified, then consumers cannot verify 193 attestations made. In effect, without resource certification, 194 consumers are basically only certifying the assertions that the 195 creator / maintainer of the resource object has made (not if that 196 assertion is valid). 198 The RIPE community addressed this last issue by putting in a 199 foundation policy [RIPE2007-01], which requires a contractual link 200 between the RIPE NCC and the end user in direct assignment + ASN 201 assignment cases, which weren't previously covered by LIR contracts 202 for address allocations. There were a couple of intentions with this 203 policy: 205 1. There was an encumbrance placed in the policy for the LIR to 206 charge the end-user for provider independent resources. This 207 action created a collection mechanism for PI address resources 208 (IPv4 / IPv6 space, ASNs). 210 2. It guaranteed that all RIPE NCC allocated/assigned space would be 211 subject to a contractual link, and that this contractual chain 212 might end up actually meaning something when it came to the issue 213 of who made what claim about what number resource. 215 3. It tied into the RIPE NCC's object grandfathering policy which 216 ties the registration details of the end-user to the object 217 registered in the IRR database. 219 While this policy specifically addressed PI/portable space holders, 220 other regions address this issue, too. Further, it is indeed a 221 prerequisite for resource certification, though it does not directly 222 address the IRR deficiencies. 224 One of the central observations of this policy was that without a 225 chain-of-ownership functionality in IRR databases, the discussion of 226 certifying their contents becomes moot. 228 4.2. Incentives to Maintain Data within the IRR 230 A second problem with data contained in the IRRs is that the 231 incentives for resource holders to maintain both accurate and up-to- 232 date information in one, or more, IRRs; including deletion of out-of- 233 date or stale data from the IRRs can diminish rapidly when changing 234 their peering policies (such as switching transit providers). 235 Specifically, there is a very strong incentive for an ISP's customers 236 to register new routing information in the IRR, because some ISPs 237 enforce a strict policy that they will only build or update a 238 customer's prefix-lists applied to the customer's inbound eBGP 239 sessions based off information found within the IRRs. Unfortunately, 240 there is little incentive for an ISP's customers to remove out-of- 241 date information from an IRR, most likely attributed to the fact that 242 some ISPs do not use, or enforce use of, data contained within the 243 IRRs to automatically build incoming policy applied to customer's 244 eBGP sessions. For example, if a customer is terminating service 245 from one ISP that requires use of IRR data to build incoming policy 246 and, at the same time, enabling service with another ISP that does 247 not require use of IRR data, then that customer will likely let the 248 data in the IRR become stale or inaccurate. 250 Further, policy filters are almost exclusively generated based on the 251 origin AS information contained within IRR route objects and used by 252 providers to filter downstream transit customers. Since providers 253 only look for route objects containing the origin AS of their 254 downstream customer(s), stale route objects with historical and, 255 possibly, incorrect origin AS information are ignored. Assuming that 256 the downstream customer(s) do not continue to announce those routes 257 with historical, or incorrect, origin AS information in BGP to the 258 upstream provider, there is no significant incentive to remove them 259 as they do not impact offline policy filter generation nor routing on 260 the Internet. On the other hand, the main incentive that causes the 261 Service Provider to work with downstream customer(s) is when the 262 resultant filter list becomes too large that it is difficult for it 263 to be stored on-board PE routers; however, this is more practically 264 an operational issue with very old, legacy PE routers, not more 265 modern PE router hardware with more robust Control Plane Engines. 267 4.3. Inability for Third Parties to Remove (Stale) Information from the 268 IRRs 270 A third challenge with data contained in IRRs is that it is not 271 possible for IRR operators, and ISPs who use them, to proactively 272 remove (perceived) out-of-date or "stale" resources in an IRR, on 273 behalf of resource holders who may not be diligent in maintaining 274 this information themselves. The reason is that, according to the 275 Resource Policy Specification Language (RPSL) [RFC2622], only the 276 resource holder ('mntner') specified in a 'mnt-by' value field of an 277 RPSL resource is authorized to add, modify or delete their own 278 resources within the IRR. To address this issue, the 'auth-override' 279 mechanism [RFC2725] was later developed that would have enabled a 280 third party to update and/or remove "stale" resources from the IRR. 281 While it is unclear if this was ever implemented or deployed, it does 282 provide language semantics needed to overcome this obstacle. 284 Nevertheless, with such a mechanism in place, there is still a risk 285 that the original RPSL resource holder would not receive 286 notifications (via the 'notify' attribute in various RPSL resources) 287 about the pending or actual removal of a resource from the IRR in 288 time to halt that action if those resources were still being used. 289 In this case, if the removal of a resource was not suspended, it 290 could potentially result in an unintentional denial of service for 291 the RPSL resource holder when, for example, ISPs automatically 292 generated and deployed a new policy based on the newly removed 293 resources from the IRR, thus dropping any reachability announcement 294 for the removed resource in eBGP. 296 4.4. Lack of Authoritative IRR for Resources 298 According to [RFC2622], within an RPSL resource "the source attribute 299 specifies the registry where the object is registered." Note that 300 this source attribute only exists within the RPSL resource itself. 301 Unfortunately, given a specific resource, (e.g.: a specific IPv4 or 302 IPv6 prefix), most of the time it is impossible to tell a priori the 303 authoritative IRR where to query and retrieve an authoritative copy 304 of that resource. 306 This makes it difficult for consumers of data from the IRR to 307 automatically know the authoritative IRR of a resource holder, which 308 will contain their most up-to-date set of resources. This is 309 typically not a problem for an ISP that has a direct (customer) 310 relationship with the resource holder, because the ISP will ask the 311 resource holder which (authoritative) IRR to pull their resources 312 from on, for example, a "Customer BGP Order Form". However, third 313 parties that do not have a direct relationship with the resource 314 holder, have a difficult time attempting to infer the authoritative 315 IRR, preferred by the resource holder, that likely contains the most 316 up-to-date set of resources. As a result, it would be helpful for 317 third parties if there was a robust referral mechanism so that a 318 query to one IRR would be automatically redirected toward the 319 authoritative IRR for the most up-to-date and authoritative copy of 320 that particular resource. This problem is worked around by 321 individual IRR operators storing a local copy of other IRR's 322 resources, through periodic mirroring, which allows the individual 323 IRR to respond to a client's query with all registered instances of a 324 particular IRR resource that exist in both the local IRR and all 325 other IRRs. Of course, the problem with this approach is that an 326 individual IRR operator is under no obligation to mirror all other 327 IRRs and, in practice, some IRRs do not mirror the resources from all 328 other IRRs. This could lead to the false impression that a 329 particular resource is not registered or maintained at a particular 330 IRR. Furthermore, the authentication process of accepting updates by 331 any given IRR may, or may not, be robust enough to overcome 332 impersonation attacks. As a result, there is no rigorous assurance 333 that a mirrored RPSL statement was actually made by the authorized 334 resource holder. 336 4.5. Conclusions with respect to Data in the IRR 338 All of the aforementioned issues related to integrity and accuracy of 339 data within the IRR stem from a distinct lack of resource 340 certification for resources contained within the IRR. Only now is an 341 experimental test bed that reports to provide this function (under 342 the auspices of the Resource PKI [RFC6480]) being formally discussed, 343 which could also aid in certification of resources within the IRR. 344 It should be noted that the RPKI is only currently able to support 345 signing of Route Origin Authorization (ROA) resources that are the 346 equivalent of 'route' resources in the IRR. It is unclear if, in the 347 future, the RPKI will be extended to support additional resources 348 that already exist in the IRR, e.g.: aut-num, as-net, route-set, etc. 349 Finally, a seemingly equivalent resource certification specification 350 for all resources in the IRR has already been developed [RFC2725], 351 however it is unclear how widely it was ever implemented or deployed. 353 5. Operation of the IRR Infrastructure 355 5.1. Replication of Resources Among IRRs 357 Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring 358 (NRTM) protocol to replicate each others contents. However, this 359 protocol has a several weaknesses. Namely, there is no way to 360 validate that the copy of mirror is correct and synchronization 361 issues have often resulted. Furthermore, the NRTM protocol does not 362 employ any security mechanisms. The NRTM protocol relies on a pull 363 mechanism and is generally is configured with a poll interval of 5 to 364 10 minutes. There is currently no mechanism to notify an IRR when an 365 update has occurred in a mirrored IRR so that an immediate update can 366 be made. 368 Some providers employ a process of mirroring an instance of an IRR 369 that involves downloading a flat text file copy of the IRR that is 370 made available via FTP. These FTP files are exported at regular 371 intervals of typically anywhere between 2 and 24 hours by the IRRs. 372 When a provider fetches those text files, it will process them to 373 identify any updates and reflect changes within its own internally 374 maintained database. The use of an internally maintained database is 375 out-of-scope of this document, but is generally used to assist with 376 more straightforward access to or modification of data by the IRR 377 operator. Providers typically employ a 24 hour cycle to pull updated 378 resources from IRRs. Thus, depending on when resource holders 379 submitted their changes to an IRR, it may take up to 24 hours for 380 those changes to be reflected in their policy configurations. In 381 practice, it appears that the RPKI will also employ a 24 hour cycle 382 whereby changes in resources are pushed out to other RPKI caches 384 [REF?]. 386 IRRs originated from Section 7 of [RFC1787], specifically: "The scale 387 of the Internet implies that the [routing requirements] information 388 should be distributed." Regardless, the practical effect of an 389 organization maintaining its own local cache of IRR resources is an 390 increase in resource resiliency (due to multiple copies of the same 391 resource being geographically distributed), a reduction in query time 392 for resources and, likely, a reduction in bandwidth consumption and 393 associated costs. This is particularly beneficial when, for example, 394 an ISP is evaluating resources in an IRR just to determine if there 395 are any modifications to those resources that will ultimately be 396 reflected in a new routing policy that will get propagated to (Edge) 397 routers in the ISP's network. Cache locality results in reduced 398 bandwidth utilization for each round trip. 400 On the other hand, it is unclear from where the current provider 401 replication interval of 24 hours originated or even whether it still 402 provides enough freshness in the face of available resources, 403 particularly in today's environment where a typical IRR system 404 consists of a (multi-core) multi-GHz CPU connected to a network via a 405 physical connection of 100 Mbps or, more likely, higher bandwidth. 406 In addition, it can be observed that the most common circuit size 407 used by ISPs is now 10 Gbps, thus eliminating bandwidth as a 408 significant factor in the transfer of data between IRRs. 409 Furthermore, it should be noted that Merit's Internet Routing 410 Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default 411 for "irr_mirror_interval". 413 Lastly, it should be noted that [RFC2769], Routing Policy System 414 Replication, attempted to offer a more methodical solution for 415 distributed replication of resources between IRRs. It is unclear why 416 this RFC failed to gain traction, but it is suspected that this was 417 due to that specification's reliance on [RFC2725], Routing Policy 418 System Security, that addressed "the need to assure integrity of the 419 data by providing an authentication and authorization model." 421 5.2. Updating Routing Policies from Updated IRR Resources 423 Ultimately, the length of time it takes to replicate resources among 424 IRRs is, generally, the dominant factor in reflecting changes to 425 resources in policy that is eventually applied within the Control 426 Plane of routers. The length of time to update network elements will 427 vary considerably depending on the size of the ISP and the number of 428 IRR resources that were updated during any given interval. However, 429 there are a variety of common techniques, that are outside the scope 430 of this document, that allow for this automated process to be 431 optimized to considerably reduce the length of time it takes to 432 update policies in the ISP's network. 434 An ISP will begin the process of updating the policy in their 435 network, by first fetching IRR resources associated with, for 436 example, a customer ASN attached to their network. Next, the ISP 437 constructs a new policy associated to that customer and then 438 evaluates if that new policy is different from existing policy 439 associated with that same customer. If there are no changes between 440 the new and existing policy associated with that customer, then the 441 ISP does not make any changes to the policy in their routers specific 442 to that customer. On the other hand, if the new policy does reflect 443 changes from the existing policy for that customer, then the ISP 444 begins a process of uploading the new policy to the routers attached 445 to that customer. 447 The process of constructing a new policy involves use of a set of 448 programs, e.g.: IRRtoolset, that performs recursive expansion of an 449 RPSL aut-num resource, that comprises an arbitrary combination of 450 other RPSL aut-num, as-set, route and route-set resources, according 451 to procedures defined by RPSL. The end result of this process is, 452 traditionally, a router vendor dependent configuration snippet that 453 defines the routing policy for that customer. This routing policy 454 may consist of the set of IPv4 or IPv6 prefixes, associated prefix 455 lengths and AS_PATH's that are supposed to be accepted from a 456 customer's eBGP session. However, if indicated in the appropriate 457 RPSL resource, the policy may also set certain BGP Attributes, such 458 as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the 459 incoming eBGP session from the customer or on static routes that are 460 originated by the resource holder. 462 An ISP's customers may not adequately plan for pre-planned 463 maintenance or, more likely, need to rapidly begin announcing a new 464 IP prefix as a result of, for example, an emergency turn-up of the 465 ISP customer's new downstream customer. Unfortunately, the routine, 466 automated process employed by the ISP means that they may not begin 467 updating their routing policy on their network for up to 24 hours, 468 because the ISP or the IRRs the ISP uses might only mirror changes to 469 IRR resources once every 24 hours. The time interval for the 470 routine/automated process is not responsive to the needs of directly 471 paying customer(s) who need rapid changes in their policy in rare 472 situations. In these situations, when a customer has an urgent need 473 for updates to take affect immediately, they will call up the Network 474 Operations Center (NOC) of their ISP and request that the ISP 475 immediately fetch new IRR objects and push those changes out to their 476 network. This is often accomplished in as little as five minutes 477 from the time a customer contacts their ISP's NOC to the time a new 478 filtering policy is pushed out to the PE routers that are attached to 479 that customer's Attachment Circuits (AC's). It is conceivable that 480 some ISPs automate this using out-of-band mechanisms as well, 481 although the authors are unaware of any existing mechanisms that 482 support this. 484 Ultimately, the aforementioned latency with respect to "emergency 485 changes" in IRR resources that need to be reflected in near-real-time 486 in the network is compounded if the IRR resources were being used by 487 third party ISPs to perform filtering on their peering circuits, 488 where typically no such policies are employed today for this very 489 reason. It is likely that the length of time at which IRRs mirror 490 changes will have to be dramatically reduced with a corresponding 491 reduction in time at the ISPs that, in turn, need to evaluate whether 492 changes in a set of IRR resources need to get reflected in updated 493 router policies that will get pushed out to ASBR's, connected to 494 peering circuits, on their network. 496 6. Historical BGP Protocol Limitations 498 As mentioned previously, after a resource holder made changes to 499 their resources in an IRR, those changes would automatically be 500 distributed to other IRRs, ISPs would then learn of those changes, 501 generate a new BGP policies, and then apply those to the appropriate 502 subset of routers in their ASes. However, in the past, one 503 additional step is necessary in order to have any of those new BGP 504 policies take effect in the Control Plane and to allow/deny the 505 updated resource from a customer to their ISP and from their 506 immediately upstream ISP to the ISP's peers. It was necessary (often 507 manually) to actually induce BGP on each router to apply the new 508 policy within the Control Plane, thus learning of a newly announced/ 509 changed IP prefix (or, dropping a deleted IP prefix). Unfortunately, 510 most of these methods were not only highly operationally impactful, 511 but also affected traffic forwarding to IP destinations that were 512 unrelated to the most recent changes to the BGP policy. 514 Historically, a customer would have to (re-)announce the new IP 515 prefix toward their ISP, but only after the ISP had placed the new 516 BGP policies into affect. Alternatively, the ISP would have to reset 517 the entire PE-CE eBGP session either by: a) bouncing the entire 518 interface toward the customer, (e.g.: shutdown/no shutdown); or, b) 519 clearing the eBGP session toward the customer, (e.g.: clear ip bgp 520 neighbor >IP address of CE router<). The latter two cases were, of 521 course, the most highly impactful and thus could generally only be 522 performed off-hours during a maintenance window. 524 Once the new IP prefix has been successfully announced by the 525 customer and permitted by the newly updated policy at the ISP's PE's 526 (attached to that customer), it would be propagated to that ISP's 527 ASBR's, attached to peers, at the perimeter of the ISP network. 528 Unfortunately, if those peers had either not yet learned of the 529 changes to resources in the IRR or pushed out new BGP policies (and, 530 reset their BGP sessions immediately afterward) incorporating those 531 changes, then the newly announced route would also get dropped at the 532 ingress ASBR's of the peers. 534 Ultimately, either of the two scenarios above further lengthen the 535 effective time it would take for changes in IRR resources to take 536 affect within BGP in the network. Fortunately, BGP has been enhanced 537 over the last several years in order that changes within BGP policy 538 will take affect without requiring a service impacting reset of BGP 539 sessions. Specifically, BGP soft-reconfiguration [REF?] and, later, 540 Route Refresh Capability for BGP-4 [RFC2918] were developed so that 541 ISPs, or their customers, could induce BGP to apply a new policy 542 while leaving both the existing eBGP session active as well as 543 (unaffected) routes active in both the Loc-RIB and, more importantly, 544 FIB of the router. Thus, using either of these mechanisms, an ISP or 545 its peers currently will deploy a newly generated BGP policy, based 546 on changes to resources within the IRR, and immediately trigger a 547 non-service impacting notification to the BGP process to have those 548 changes take affect in their Control Plane, either allowing a new IP 549 prefix to be announced or an old IP prefix to be dropped. This 550 dramatically reduces the length of time after changes are propagated 551 throughout the IRRs to when those changes are actually operational 552 within BGP policy in an ISP's network. 554 7. Historical Limitations of Routers 556 7.1. Incremental Updates to Policy on Routers 558 Routers in the mid 1990's rarely supported incrementally updatable 559 prefix filters for BGP, and therefore, if new information was 560 received from a policy or internal configuration database that would 561 impact a policy applied to a given eBGP peer, the entire prefix list 562 or access list would need to be deleted and rewritten, compiled, and 563 installed. This was very tedious and commonly led to leaked routes 564 during the time when the policy was being rewritten, compiled, and 565 applied on a router. Furthermore, application of a new policy would 566 not automatically result in new ingress or egress reachability 567 advertisements, from that new policy, because routers at the time 568 would require a reset of the eBGP sessions for routing information to 569 be evaluated by the new policy. Of course, resetting of an eBGP 570 session had implications on traffic forwarding during the time the 571 eBGP session was reestablished and new routing information was 572 learned. 574 Routers now support the ability to perform incremental, and in situ, 575 updates to filter lists consisting of IP prefixes and/or AS_PATH's 576 that are used within an ingress or egress BGP policy. In addition, 577 routers also can apply those incremental updates to policy, with no 578 traffic disruption, using BGP soft-reconfiguration or BGP Route 579 Refresh, as discussed in the previous section. 581 7.2. Storage Requirements for Policy on Routers 583 Historically, routers had very limited storage capacity and would 584 have difficulty in storing an extremely large BGP policy on-board. 585 This was typically the result of router hardware vendors using an 586 extremely limited amount of NVRAM for storage of router 587 configurations. 589 Another challenge with historical router hardware was that writing to 590 NVRAM was extremely slow. Thus, when the router configuration had 591 changed as a result of, for example, updating a BGP policy to 592 accommodate changes in IRR resources, this would result in extremely 593 long times to write out these configuration changes and, sometimes, 594 due to bugs would result in loss of protocol keep-alives, thus 595 causing an impact to routing or forwarding of packets through the 596 platform. 598 The above limitations have largely been resolved with more modern 599 equipment from the last few years shipping with increasing amounts of 600 non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk 601 Drives or Solid State Disk Drives. 603 7.3. Updating Configuration on Routers 605 Historically, there has not been a standardized network configuration 606 modeling language or an associated method to update router 607 configurations. When an ISP detected a change in resources within 608 the IRR, it would fashion a router vendor dependent BGP policy and 609 upload that to the router usually via the following method. 611 First, an updated BGP policy configuration 'snippet' is generated via 612 processes running on an offline server. Next, the operator uses 613 either telnet or SSH to login to the CLI of a target router and issue 614 router vendor dependent CLI commands that will trigger the target 615 router to fetch the new configuration snippet via TFTP, FTP or Secure 616 Copy (SCP) stored on the offline server. The target router will then 617 perform syntax checking on that configuration snippet and, if that 618 passes, merge that configuration snippet into the running 619 configuration of the router's Control Software. At this point, the 620 new BGP policy configuration 'snippet' is active within the Control 621 Plane of the router. One last step remains, which is the operator 622 will issue a CLI command to induce the router to perform a "soft 623 reset", via BGP soft-reconfiguration or BGP Route Refresh, of the 624 associated BGP session in order to trigger the router to apply the 625 new policy to routes learned from that BGP session without disrupting 626 traffic forwarding. 628 More recently, operators have the ability to use NETCONF/SSH (or, 629 TLS) from an offline server to push a BGP configuration 'snippet' 630 from an offline server toward a target router that has that 631 capability. However, this activity is still dependent on generating, 632 via the offline server, a router vendor dependent XML configuration 633 snippet that would get uploaded via SSH or TLS to the target router. 635 In the future, the ability to upload new Route Origin Authorization 636 (ROA) information may be provided from the RPKI to routers via the 637 RPKI-RTR [RFC6810] protocol. However, this will not allow operators 638 the ability to upload other configuration information such as BGP 639 policy information, such as AS_PATH's, BGP communities, etc. that 640 might be associated with that ROA information, like they can from IRR 641 generated BGP policies. 643 8. Security Considerations 645 9. IANA Considerations 647 10. Acknowledgements 649 TBD. 651 11. Informative References 653 [MERIT-IRRD] 654 Merit, "IRRd - Internet Routing Registry Daemon", 655 http://www.irrd.net. 657 [RC_HotNetsX] 658 "The Great IPv4 Land Grab: Resource Certification for the 659 IPv4 Grey Market", 660 HotNets-X http://dl.acm.org/citation.cfm?id=2070574. 662 [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", 663 RFC 1787, April 1995. 665 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 666 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 667 "Routing Policy Specification Language (RPSL)", RFC 2622, 668 June 1999. 670 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 671 Murphy, "Routing Policy System Security", RFC 2725, 672 December 1999. 674 [RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. 675 Meyer, "Routing Policy System Replication", RFC 2769, 676 February 2000. 678 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 679 September 2000. 681 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 682 Secure Internet Routing", RFC 6480, February 2012. 684 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 685 Infrastructure (RPKI) to Router Protocol", RFC 6810, 686 January 2013. 688 [RIPE2007-01] 689 RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment 690 Policies and Procedures", Foundation 691 Policy http://www.ripe.net/ripe/docs/ripe-452. 693 Authors' Addresses 695 Danny McPherson 696 Verisign, Inc. 698 Email: dmcpherson@verisign.com 700 Shane Amante 701 Level 3 Communications 702 1025 Eldorado Blvd 703 Broomfield, CO 80021 704 USA 706 Email: shane@level3.net 707 Eric Osterweil 708 Verisign, Inc. 710 Email: eosterweil@verisign.com 712 Larry J. Blunk 713 Merit Network, Inc. 715 Email: ljb@merit.edu 717 Dave Mitchell 718 Twitter, Inc. 720 Email: dave@twitter.com