idnits 2.17.1 draft-ietf-grow-irr-routing-policy-considerations-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 : ---------------------------------------------------------------------------- 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 (May 3, 2013) is 3982 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 (-26) exists of draft-ietf-sidr-rpki-rtr-20 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 4, 2013 Level 3 Communications 6 E. Osterweil 7 Verisign, Inc. 8 L. Blunk 9 Merit Network, Inc. 10 D. Mitchell 11 Twitter, Inc. 12 May 3, 2013 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 4, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . 6 74 4.5. Conclusions with respect to Data in the IRR . . . . . . . 7 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 . . . . . . . . 12 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 One of the largest weaknesses often cited with the IRR system is that 161 the data contained within the IRRs is out of date or lacks integrity. 162 This is largely attributable to the fact that historically there has 163 existed no method for developing cryptographically verifiable 164 bindings of an IP prefix to the originating Autonomous System (AS). 165 That is, there has never existed a resource certification 166 infrastructure that enables a resource holder to authorize a 167 particular autonomous system to originate network layer reachability 168 advertisements for a given IPv4 or IPv6 prefix. It should be noted 169 that this is not a weakness of the underlying Routing Policy 170 Specification Language (RPSL) [RFC2622], but rather, was largely the 171 result of no clear demand by the operator community for Internet 172 Number Resource Registries to provide sufficient resource 173 certification infrastructure that would enable a resource holder to 174 develop a cryptographic binding between, for example, a given AS 175 number and an IP prefix. 177 Another noteworthy (but slightly different) deficiency in the IRR 178 system is the absence of a tangible tie between the resource and the 179 resource holder. If a resource holder's authorization cannot be 180 certified, then consumers cannot verify attestations made. In 181 effect, without resource certification, consumers are basically only 182 certifying the assertions that the creator / maintainer of the 183 resource object has made (not if that assertion is valid). 185 The RIPE community addressed this last issue by putting in a 186 foundation policy [RIPE2007-01], which requires a contractual link 187 between the RIPE NCC and the end user in direct assignment + ASN 188 assignment cases, which weren't previously covered by LIR contracts 189 for address allocations. There were a couple of intentions with this 190 policy: 192 1. There was an encumbrance placed in the policy for the LIR to 193 charge the end-user for provider independent resources. This 194 action created a collection mechanism for PI address resources 195 (IPv4 / IPv6 space, ASNs). 197 2. It guaranteed that all RIPE NCC allocated/assigned space would be 198 subject to a contractual link, and that this contractual chain 199 might end up actually meaning something when it came to the issue 200 of who made what claim about what number resource. 202 3. It tied into the RIPE NCC's object grandfathering policy which 203 ties the registration details of the end-user to the object 204 registered in the IRR database. 206 One of the central observations of this policy was that without a 207 chain-of-ownership functionality in IRR databases, the discussion of 208 certifying their contents becomes moot. 210 4.2. Incentives to Maintain Data within the IRR 212 A second problem with data contained in the IRRs is that the 213 incentives for resource holders to maintain both accurate and up-to- 214 date information in one, or more, IRRs; including deletion of out-of- 215 date or stale data from the IRRs can diminish rapidly when changing 216 their peering policies (such as switching transit providers). 217 Specifically, there is a very strong incentive for an ISP's customers 218 to register new routing information in the IRR, because some ISPs 219 enforce a strict policy that they will only build or update a 220 customer's prefix-lists applied to the customer's inbound eBGP 221 sessions based off information found within the IRRs. Unfortunately, 222 there is little incentive for an ISP's customers to remove out-of- 223 date information from an IRR, most likely attributed to the fact that 224 some ISPs do not use, or enforce use of, data contained within the 225 IRRs to automatically build incoming policy applied to customer's 226 eBGP sessions. For example, if a customer is terminating service 227 from one ISP that requires use of IRR data to build incoming policy 228 and, at the same time, enabling service with another ISP that does 229 not require use of IRR data, then that customer will likely let the 230 data in the IRR become stale or inaccurate. 232 Further, policy filters are almost exclusively generated based on the 233 origin AS information contained within IRR route objects and used by 234 providers to filter downstream transit customers. Since providers 235 only look for route objects containing the origin AS of their 236 downstream customer(s), stale route objects with historical and, 237 possibly, incorrect origin AS information are ignored. Assuming that 238 the downstream customer(s) do not continue to announce those routes 239 with historical, or incorrect, origin AS information in BGP to the 240 upstream provider, there is no significant incentive to remove them 241 as they do not impact offline policy filter generation nor routing on 242 the Internet. On the other hand, the main incentive that causes the 243 Service Provider to work with downstream customer(s) is when the 244 resultant filter list becomes too large that it is difficult for it 245 to be stored on-board PE routers; however, this is more practically 246 an operational issue with very old, legacy PE routers, not more 247 modern PE router hardware with more robust Control Plane Engines. 249 4.3. Inability for Third Parties to Remove (Stale) Information from the 250 IRRs 252 A third challenge with data contained in IRRs is that it is not 253 possible for IRR operators, and ISPs who use them, to proactively 254 remove (perceived) out-of-date or "stale" resources in an IRR, on 255 behalf of resource holders who may not be diligent in maintaining 256 this information themselves. The reason is that, according to the 257 Resource Policy Specification Language (RPSL) [RFC2622], only the 258 resource holder ('mntner') specified in a 'mnt-by' value field of an 259 RPSL resource is authorized to add, modify or delete their own 260 resources within the IRR. To address this issue, the 'auth-override' 261 mechanism [RFC2725] was later developed that would have enabled a 262 third party to update and/or remove "stale" resources from the IRR. 263 While it is unclear if this was ever implemented or deployed, it does 264 provide language semantics needed to overcome this obstacle. 266 Nevertheless, with such a mechanism in place, there is still a risk 267 that the original RPSL resource holder would not receive 268 notifications (via the 'notify' attribute in various RPSL resources) 269 about the pending or actual removal of a resource from the IRR in 270 time to halt that action if those resources were still being used. 271 In this case, if the removal of a resource was not suspended, it 272 could potentially result in an unintentional denial of service for 273 the RPSL resource holder when, for example, ISPs automatically 274 generated and deployed a new policy based on the newly removed 275 resources from the IRR, thus dropping any reachability announcement 276 for the removed resource in eBGP. 278 4.4. Lack of Authoritative IRR for Resources 280 According to [RFC2622], within an RPSL resource "the source attribute 281 specifies the registry where the object is registered." Note that 282 this source attribute only exists within the RPSL resource itself. 283 Unfortunately, given a specific resource, (e.g.: a specific IPv4 or 284 IPv6 prefix), most of the time it is impossible to tell a priori the 285 authoritative IRR where to query and retrieve an authoritative copy 286 of that resource. 288 This makes it difficult for consumers of data from the IRR to 289 automatically know the authoritative IRR of a resource holder, which 290 will contain their most up-to-date set of resources. This is 291 typically not a problem for an ISP that has a direct (customer) 292 relationship with the resource holder, because the ISP will ask the 293 resource holder which (authoritative) IRR to pull their resources 294 from on, for example, a "Customer BGP Order Form". However, third 295 parties that do not have a direct relationship with the resource 296 holder, have a difficult time attempting to infer the authoritative 297 IRR, preferred by the resource holder, that likely contains the most 298 up-to-date set of resources. As a result, it would be helpful for 299 third parties if there was a robust referral mechanism so that a 300 query to one IRR would be automatically redirected toward the 301 authoritative IRR for the most up-to-date and authoritative copy of 302 that particular resource. This problem is worked around by 303 individual IRR operators storing a local copy of other IRR's 304 resources, through periodic mirroring, which allows the individual 305 IRR to respond to a client's query with all registered instances of a 306 particular IRR resource that exist in both the local IRR and all 307 other IRRs. Of course, the problem with this approach is that an 308 individual IRR operator is under no obligation to mirror all other 309 IRRs and, in practice, some IRRs do not mirror the resources from all 310 other IRRs. This could lead to the false impression that a 311 particular resource is not registered or maintained at a particular 312 IRR. Furthermore, the authentication process of accepting updates by 313 any given IRR may, or may not, be robust enough to overcome 314 impersonation attacks. As a result, there is no rigorous assurance 315 that a mirrored RPSL statement was actually made by the authorized 316 resource holder. 318 4.5. Conclusions with respect to Data in the IRR 320 All of the aforementioned issues related to integrity and accuracy of 321 data within the IRR stem from a distinct lack of resource 322 certification for resources contained within the IRR. Only now is an 323 experimental test bed that reports to provide this function (under 324 the auspices of the Resource PKI [I-D.ietf-sidr-arch]) being formally 325 discussed, which could also aid in certification of resources within 326 the IRR. It should be noted that the RPKI is only currently able to 327 support signing of Route Origin Authorization (ROA) resources that 328 are the equivalent of 'route' resources in the IRR. It is unclear 329 if, in the future, the RPKI will be extended to support additional 330 resources that already exist in the IRR, e.g.: aut-num, as-net, 331 route-set, etc. Finally, a seemingly equivalent resource 332 certification specification for all resources in the IRR has already 333 been developed [RFC2725], however it is unclear how widely it was 334 ever implemented or deployed. 336 5. Operation of the IRR Infrastructure 338 5.1. Replication of Resources Among IRRs 340 Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring 341 (NRTM) protocol to replicate each others contents. However, this 342 protocol has a several weaknesses. Namely, there is no way to 343 validate that the copy of mirror is correct and synchronization 344 issues have often resulted. Furthermore, the NRTM protocol does not 345 employ any security mechanisms. The NRTM protocol relies on a pull 346 mechanism and is generally is configured with a poll interval of 5 to 347 10 minutes. There is currently no mechanism to notify an IRR when an 348 update has occurred in a mirrored IRR so that an immediate update can 349 be made. 351 Some providers employ a process of mirroring an instance of an IRR 352 that involves downloading a flat text file copy of the IRR that is 353 made available via FTP. These FTP files are exported at regular 354 intervals of typically anywhere between 2 and 24 hours by the IRRs. 355 When a provider fetches those text files, it will process them to 356 identify any updates and reflect changes within its own internally 357 maintained database. The use of an internally maintained database is 358 out-of-scope of this document, but is generally used to assist with 359 more straightforward access to or modification of data by the IRR 360 operator. Providers typically employ a 24 hour cycle to pull updated 361 resources from IRRs. Thus, depending on when resource holders 362 submitted their changes to an IRR, it may take up to 24 hours for 363 those changes to be reflected in their policy configurations. In 364 practice, it appears that the RPKI will also employ a 24 hour cycle 365 whereby changes in resources are pushed out to other RPKI caches 366 [REF?]. 368 IRRs originated from Section 7 of [RFC1787], specifically: "The scale 369 of the Internet implies that the [routing requirements] information 370 should be distributed." Regardless, the practical effect of an 371 organization maintaining its own local cache of IRR resources is an 372 increase in resource resiliency (due to multiple copies of the same 373 resource being geographically distributed), a reduction in query time 374 for resources and, likely, a reduction in bandwidth consumption and 375 associated costs. This is particularly beneficial when, for example, 376 an ISP is evaluating resources in an IRR just to determine if there 377 are any modifications to those resources that will ultimately be 378 reflected in a new routing policy that will get propagated to (Edge) 379 routers in the ISP's network. Cache locality results in reduced 380 bandwidth utilization for each round trip. 382 On the other hand, it is unclear from where the current provider 383 replication interval of 24 hours originated or even whether it still 384 provides enough freshness in the face of available resources, 385 particularly in today's environment where a typical IRR system 386 consists of a (multi-core) multi-Ghz CPU connected to a network via a 387 physical connection of 100 Mbps or, more likely, higher bandwidth. 388 In addition, it can be observed that the most common circuit size 389 used by ISPs is now 10 Gbps, thus eliminating bandwidth as a 390 significant factor in the transfer of data between IRRs. 391 Furthermore, it should be noted that Merit's Internet Routing 392 Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default 393 for "irr_mirror_interval". 395 Lastly, it should be noted that [RFC2769], Routing Policy System 396 Replication, attempted to offer a more methodical solution for 397 distributed replication of resources between IRRs. It is unclear why 398 this RFC failed to gain traction, but it is suspected that this was 399 due to that specification's reliance on [RFC2725], Routing Policy 400 System Security, that addressed "the need to assure integrity of the 401 data by providing an authentication and authorization model." 403 5.2. Updating Routing Policies from Updated IRR Resources 405 Ultimately, the length of time it takes to replicate resources among 406 IRRs is, generally, the dominant factor in reflecting changes to 407 resources in policy that is eventually applied within the Control 408 Plane of routers. The length of time to update network elements will 409 vary considerably depending on the size of the ISP and the number of 410 IRR resources that were updated during any given interval. However, 411 there are a variety of common techniques, that are outside the scope 412 of this document, that allow for this automated process to be 413 optimized to considerably reduce the length of time it takes to 414 update policies in the ISP's network. 416 An ISP will begin the process of updating the policy in their 417 network, by first fetching IRR resources associated with, for 418 example, a customer ASN attached to their network. Next, the ISP 419 constructs a new policy associated to that customer and then 420 evaluates if that new policy is different from existing policy 421 associated with that same customer. If there are no changes between 422 the new and existing policy associated with that customer, then the 423 ISP does not make any changes to the policy in their routers specific 424 to that customer. On the other hand, if the new policy does reflect 425 changes from the existing policy for that customer, then the ISP 426 begins a process of uploading the new policy to the routers attached 427 to that customer. 429 The process of constructing a new policy involves use of a set of 430 programs, e.g.: IRRtoolset, that performs recursive expansion of an 431 RPSL aut-num resource, that comprises an arbitrary combination of 432 other RPSL aut-num, as-set, route and route-set resources, according 433 to procedures defined by RPSL. The end result of this process is, 434 traditionally, a router vendor dependent configuration snippet that 435 defines the routing policy for that customer. This routing policy 436 may consist of the set of IPv4 or IPv6 prefixes, associated prefix 437 lengths and AS_PATH's that are supposed to be accepted from a 438 customer's eBGP session. However, if indicated in the appropriate 439 RPSL resource, the policy may also set certain BGP Attributes, such 440 as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the 441 incoming eBGP session from the customer or on static routes that are 442 originated by the resource holder. 444 An ISP's customers may not adequately plan for pre-planned 445 maintenance or, more likely, need to rapidly begin announcing a new 446 IP prefix as a result of, for example, an emergency turn-up of the 447 ISP customer's new downstream customer. Unfortunately, the routine, 448 automated process employed by the ISP means that they may not begin 449 updating their routing policy on their network for up to 24 hours, 450 because the ISP or the IRRs the ISP uses might only mirror changes to 451 IRR resources once every 24 hours. The time interval for the 452 routine/automated process is not responsive to the needs of directly 453 paying customer(s) who need rapid changes in their policy in rare 454 situations. In these situations, when a customer has an urgent need 455 for updates to take affect immediately, they will call up the Network 456 Operations Center (NOC) of their ISP and request that the ISP 457 immediately fetch new IRR objects and push those changes out to their 458 network. This is often accomplished in as little as five minutes 459 from the time a customer contacts their ISP's NOC to the time a new 460 filtering policy is pushed out to the PE routers that are attached to 461 that customer's Attachment Circuits (AC's). It is conceivable that 462 some ISPs automate this using out-of-band mechanisms as well, 463 although the authors are unaware of any existing mechanisms that 464 support this. 466 Ultimately, the aforementioned latency with respect to "emergency 467 changes" in IRR resources that need to be reflected in near-real-time 468 in the network is compounded if the IRR resources were being used by 469 third party ISPs to perform filtering on their peering circuits, 470 where typically no such policies are employed today for this very 471 reason. It is likely that the length of time at which IRRs mirror 472 changes will have to be dramatically reduced with a corresponding 473 reduction in time at the ISPs that, in turn, need to evaluate whether 474 changes in a set of IRR resources need to get reflected in updated 475 router policies that will get pushed out to ASBR's, connected to 476 peering circuits, on their network. 478 6. Historical BGP Protocol Limitations 480 As mentioned previously, after a resource holder made changes to 481 their resources in an IRR, those changes would automatically be 482 distributed to other IRRs, ISPs would then learn of those changes, 483 generate a new BGP policies, and then apply those to the appropriate 484 subset of routers in their ASes. However, in the past, one 485 additional step is necessary in order to have any of those new BGP 486 policies take effect in the Control Plane and to allow/deny the 487 updated resource from a customer to their ISP and from their 488 immediately upstream ISP to the ISP's peers. It was necessary (often 489 manually) to actually induce BGP on each router to apply the new 490 policy within the Control Plane, thus learning of a newly announced/ 491 changed IP prefix (or, dropping a deleted IP prefix). Unfortunately, 492 most of these methods were not only highly operationally impactful, 493 but also affected traffic forwarding to IP destinations that were 494 unrelated to the most recent changes to the BGP policy. 496 Historically, a customer would have to (re-)announce the new IP 497 prefix toward their ISP, but only after the ISP had placed the new 498 BGP policies into affect. Alternatively, the ISP would have to reset 499 the entire PE-CE eBGP session either by: a) bouncing the entire 500 interface toward the customer, (e.g.: shutdown/no shutdown); or, b) 501 clearing the eBGP session toward the customer, (e.g.: clear ip bgp 502 neighbor >IP address of CE router<). The latter two cases were, of 503 course, the most highly impactful and thus could generally only be 504 performed off-hours during a maintenance window. 506 Once the new IP prefix has been successfully announced by the 507 customer and permitted by the newly updated policy at the ISP's PE's 508 (attached to that customer), it would be propagated to that ISP's 509 ASBR's, attached to peers, at the perimeter of the ISP network. 510 Unfortunately, if those peers had either not yet learned of the 511 changes to resources in the IRR or pushed out new BGP policies (and, 512 reset their BGP sessions immediately afterward) incorporating those 513 changes, then the newly announced route would also get dropped at the 514 ingress ASBR's of the peers. 516 Ultimately, either of the two scenarios above further lengthen the 517 effective time it would take for changes in IRR resources to take 518 affect within BGP in the network. Fortunately, BGP has been enhanced 519 over the last several years in order that changes within BGP policy 520 will take affect without requiring a service impacting reset of BGP 521 sessions. Specifically, BGP soft-reconfiguration [REF?] and, later, 522 Route Refresh Capability for BGP-4 [RFC2918] were developed so that 523 ISPs, or their customers, could induce BGP to apply a new policy 524 while leaving both the existing eBGP session active as well as 525 (unaffected) routes active in both the Loc-RIB and, more importantly, 526 FIB of the router. Thus, using either of these mechanisms, an ISP or 527 its peers currently will deploy a newly generated BGP policy, based 528 on changes to resources within the IRR, and immediately trigger a 529 non-service impacting notification to the BGP process to have those 530 changes take affect in their Control Plane, either allowing a new IP 531 prefix to be announced or an old IP prefix to be dropped. This 532 dramatically reduces the length of time after changes are propagated 533 throughout the IRRs to when those changes are actually operational 534 within BGP policy in an ISP's network. 536 7. Historical Limitations of Routers 538 7.1. Incremental Updates to Policy on Routers 540 Routers in the mid 1990's rarely supported incrementally updatable 541 prefix filters for BGP, and therefore, if new information was 542 received from a policy or internal configuration database that would 543 impact a policy applied to a given eBGP peer, the entire prefix list 544 or access list would need to be deleted and rewritten, compiled, and 545 installed. This was very tedious and commonly led to leaked routes 546 during the time when the policy was being rewritten, compiled, and 547 applied on a router. Furthermore, application of a new policy would 548 not automatically result in new ingress or egress reachability 549 advertisements, from that new policy, because routers at the time 550 would require a reset of the eBGP sessions for routing information to 551 be evaluated by the new policy. Of course, resetting of an eBGP 552 session had implications on traffic forwarding during the time the 553 eBGP session was reestablished and new routing information was 554 learned. 556 Routers now support the ability to perform incremental, and in situ, 557 updates to filter lists consisting of IP prefixes and/or AS_PATH's 558 that are used within an ingress or egress BGP policy. In addition, 559 routers also can apply those incremental updates to policy, with no 560 traffic disruption, using BGP soft-reconfiguration or BGP Route 561 Refresh, as discussed in the previous section. 563 7.2. Storage Requirements for Policy on Routers 565 Historically, routers had very limited storage capacity and would 566 have difficulty in storing an extremely large BGP policy on-board. 567 This was typically the result of router hardware vendors using an 568 extremely limited amount of NVRAM for storage of router 569 configurations. 571 Another challenge with historical router hardware was that writing to 572 NVRAM was extremely slow. Thus, when the router configuration had 573 changed as a result of, for example, updating a BGP policy to 574 accommodate changes in IRR resources, this would result in extremely 575 long times to write out these configuration changes and, sometimes, 576 due to bugs would result in loss of protocol keep-alives, thus 577 causing an impact to routing or forwarding of packets through the 578 platform. 580 The above limitations have largely been resolved with more modern 581 equipment from the last few years shipping with increasing amounts of 582 non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk 583 Drives or Solid State Disk Drives. 585 7.3. Updating Configuration on Routers 587 Historically, there has not been a standardized network configuration 588 modeling language or an associated method to update router 589 configurations. When an ISP detected a change in resources within 590 the IRR, it would fashion a router vendor dependent BGP policy and 591 upload that to the router usually via the following method. 593 First, an updated BGP policy configuration 'snippet' is generated via 594 processes running on an offline server. Next, the operator uses 595 either telnet or SSH to login to the CLI of a target router and issue 596 router vendor dependent CLI commands that will trigger the target 597 router to fetch the new configuration snippet via TFTP, FTP or Secure 598 Copy (SCP) stored on the offline server. The target router will then 599 perform syntax checking on that configuration snippet and, if that 600 passes, merge that configuration snippet into the running 601 configuration of the router's Control Software. At this point, the 602 new BGP policy configuration 'snippet' is active within the Control 603 Plane of the router. One last step remains, which is the operator 604 will issue a CLI command to induce the router to perform a "soft 605 reset", via BGP soft-reconfiguration or BGP Route Refresh, of the 606 associated BGP session in order to trigger the router to apply the 607 new policy to routes learned from that BGP session without disrupting 608 traffic forwarding. 610 More recently, operators have the ability to use NETCONF/SSH (or, 611 TLS) from an offline server to push a BGP configuration 'snippet' 612 from an offline server toward a target router that has that 613 capability. However, this activity is still dependent on generating, 614 via the offline server, a router vendor dependent XML configuration 615 snippet that would get uploaded via SSH or TLS to the target router. 617 In the future, the ability to upload new Route Origin Authorization 618 (ROA) information may be provided from the RPKI to routers via the 619 RPKI-RTR [I-D.ietf-sidr-rpki-rtr] protocol. However, this will not 620 allow operators the ability to upload other configuration information 621 such as BGP policy information, such as AS_PATH's, BGP communities, 622 etc. that might be associated with that ROA information, like they 623 can from IRR generated BGP policies. 625 8. Security Considerations 627 9. IANA Considerations 629 10. Acknowledgements 631 TBD. 633 11. Informative References 635 [I-D.ietf-sidr-arch] 636 Lepinski, M. and S. Kent, "An Infrastructure to Support 637 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 638 progress), May 2011. 640 [I-D.ietf-sidr-rpki-rtr] 641 Bush, R. and R. Austein, "The RPKI/Router Protocol", 642 draft-ietf-sidr-rpki-rtr-20 (work in progress), 643 November 2011. 645 [MERIT-IRRD] 646 Merit, "IRRd - Internet Routing Registry Daemon", 647 http://www.irrd.net. 649 [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", 650 RFC 1787, April 1995. 652 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 653 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 654 "Routing Policy Specification Language (RPSL)", RFC 2622, 655 June 1999. 657 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 658 Murphy, "Routing Policy System Security", RFC 2725, 659 December 1999. 661 [RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. 662 Meyer, "Routing Policy System Replication", RFC 2769, 663 February 2000. 665 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 666 September 2000. 668 [RIPE2007-01] 669 RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment 670 Policies and Procedures", Foundation 671 Policy http://www.ripe.net/ripe/docs/2007-01-asn. 673 Authors' Addresses 675 Danny McPherson 676 Verisign, Inc. 678 Email: dmcpherson@verisign.com 680 Shane Amante 681 Level 3 Communications 682 1025 Eldorado Blvd 683 Broomfield, CO 80021 684 USA 686 Email: shane@level3.net 688 Eric Osterweil 689 Verisign, Inc. 691 Email: eosterweil@verisign.com 693 Larry J. Blunk 694 Merit Network, Inc. 696 Email: ljb@merit.edu 698 Dave Mitchell 699 Twitter, Inc. 701 Email: dave@twitter.com