idnits 2.17.1 draft-grow-irr-routing-policy-considerations-00.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 (December 18, 2012) is 4140 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: June 21, 2013 Level 3 Communications 6 E. Osterweil 7 Verisign, Inc. 8 L. Blunk 9 Merit Network, Inc. 10 December 18, 2012 12 IRR & Routing Policy Configuration Considerations 13 15 Abstract 17 The purpose of this document is to catalog past issues influencing 18 the efficacy of Internet Routing Registries (IRR) for inter-domain 19 routing policy specification and application in the global routing 20 system over the past two decades. Additionally, it provides a 21 discussion regarding which of these issues are still problematic in 22 practice, and which are simply artifacts that are no longer 23 applicable but continue to stifle inter-provider policy-based 24 filtering adoption and IRR utility to this day. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 21, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3 66 4. Accuracy and Integrity of Data Contained within the IRR . . . 4 67 4.1. Lack of Resource Certification . . . . . . . . . . . . . . 4 68 4.2. Incentives to Maintain Data within the IRR . . . . . . . . 4 69 4.3. Inability for Third Parties to Remove (Stale) 70 Information from the IRRs . . . . . . . . . . . . . . . . 5 71 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 6 72 4.5. Conclusions with respect to Data in the IRR . . . . . . . 7 74 5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 7 75 5.1. Replication of Resources Among IRRs . . . . . . . . . . . 7 76 5.2. Updating Routing Policies from Updated IRR Resources . . . 8 78 6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 10 80 7. Historical Limitations of Routers . . . . . . . . . . . . . . 11 81 7.1. Incremental Updates to Policy on Routers . . . . . . . . . 11 82 7.2. Storage Requirements for Policy on Routers . . . . . . . . 12 83 7.3. Updating Configuration on Routers . . . . . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 91 11. Informative References . . . . . . . . . . . . . . . . . . . . 13 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 The purpose of this document is to catalog past issues influencing 98 the efficacy of Internet Routing Registries (IRR) for inter-domain 99 routing policy specification and application in the global routing 100 system over the past two decades. Additionally, it provides a 101 discussion regarding which of these issues still pose problems in 102 practice, and which are no longer obstacles, but whose perceived 103 drawbacks continue to stifle inter-provider policy-based filtering 104 support and IRR utility to this day. 106 2. Background 108 IRRs can be used to express a multitude of Internet number bindings 109 and policy objectives, to include bindings between an origin AS and a 110 given prefix, AS and community import and export policies for a given 111 AS, as well as AS macros (as-sets in RPSL-speak) that convey the set 112 of ASes for which a given AS intends to include in some common group. 114 As quoted from Section 7 of [RFC1787], Routing in a Multi-Provider 115 Internet: 117 While ensuring Internet-wide coordination may be more and more 118 difficult, as the Internet continues to grow, stability and 119 consistency of the Internet-wide routing could significantly 120 benefit if the information about routing requirements of various 121 organizations could be shared across organizational boundaries. 122 Such information could be used in a wide variety of situations 123 ranging from troubleshooting to detecting and eliminating 124 conflicting routing requirements. The scale of the Internet 125 implies that the information should be distributed. Work is 126 currently underway to establish depositories of this information 127 (Routing Registries), as well as to develop tools that analyze, as 128 well as utilize this information. 130 3. Historical Artifacts Influencing IRR Efficacy 132 The term IRR is often used, incorrectly, as a broad catch-all term to 133 categorize issues related to the accuracy of data in the IRR, the 134 Routing Policy Specification Language (RPSL) and the operational 135 deployment of policy (derived from RPSL contained within the IRR) to 136 routers. It is important to classify these issues into distinct 137 categories so that the reader can understand which categories of 138 issues are historical artifacts that are no longer applicable and 139 which categories of issues still exist and might be addressed by the 140 IETF. 142 The following sections will separate out challenges related to the 143 IRR into the following categories. First, accuracy and integrity of 144 data contained within the IRR. Second, the Resource Policy 145 Specification Language (RPSL) used to represent various types of data 146 in the IRR. Third, operation of the IRR infrastructure, i.e.: 147 synchronization of resources from one IRR to other IRRs. Finally, 148 the methods related to extraction of policy from the IRR and the 149 input plus activation of that policy within routers. 151 4. Accuracy and Integrity of Data Contained within the IRR 153 The following section will examine issues related to accuracy and 154 integrity of data contained within the IRR. 156 4.1. Lack of Resource Certification 158 One of the largest weaknesses often cited with the IRR system is that 159 the data contained within the IRRs is out of date or lacks integrity. 160 This is largely attributable to the fact that historically there has 161 existed no method for developing cryptographically verifiable 162 bindings of an IP prefix to the originating Autonomous System (AS). 163 That is, there has never existed a resource certification 164 infrastructure that enables a resource holder to authorize a 165 particular autonomous system to originate network layer reachability 166 advertisements for a given IPv4 or IPv6 prefix. It should be noted 167 that this is not a weakness of the underlying Routing Policy 168 Specification Language (RPSL) [RFC2622], but rather, was largely the 169 result of no infrastructure investment by Internet Number Resource 170 Registries to provide sufficient resource certification 171 infrastructure that would enable a resource holder to develop a 172 cryptographic binding between, for example, a given AS number and an 173 IP prefix. 175 4.2. Incentives to Maintain Data within the IRR 177 A second problem with data contained in the IRRs is that the 178 incentives for resource holders to maintain both accurate and up-to- 179 date information in one, or more, IRRs; including deletion of out-of- 180 date or stale data from the IRRs can diminish rapidly when changing 181 their peering policies (such as switching transit providers). 182 Specifically, there is a very strong incentive for an ISP's customers 183 to register new routing information in the IRR, because some ISP's 184 enforce a strict policy that they will only build or update a 185 customer's prefix-lists applied to the customer's inbound eBGP 186 sessions based off information found within the IRRs. Unfortunately, 187 there is little incentive for an ISP's customers to remove out-of- 188 date information from an IRR, most likely attributed to the fact that 189 some ISP's do not use, or enforce use of, data contained within the 190 IRRs to automatically build incoming policy applied to customer's 191 eBGP sessions. For example, if a customer is terminating service 192 from one ISP that requires use of IRR data to build incoming policy 193 and, at the same time, enabling service with another ISP that does 194 not require use of IRR data, then that customer will likely let the 195 data in the IRR become stale or inaccurate. 197 Further, policy filters are almost exclusively generated based on the 198 origin AS information contained within IRR route objects and used by 199 providers to filter downstream transit customers. Since providers 200 only look for route objects containing the origin AS of their 201 downstream customer(s), stale route objects with historical and, 202 possibly, incorrect origin AS information are ignored. Assuming that 203 the downstream customer(s) do not continue to announce those routes 204 with historical, or incorrect, origin AS information in BGP to the 205 upstream provider, there is no significant incentive to remove them 206 as they do not impact offline policy filter generation nor routing on 207 the Internet. On the other hand, the main incentive that causes the 208 Service Provider to work with downstream customer(s) is when the 209 resultant filter list becomes too large that it is difficult for it 210 to be stored on-board PE routers; however, this is more practically 211 an operational issue with very old, legacy PE routers, not more 212 modern PE router hardware with more robust Control Plane Engines. 214 4.3. Inability for Third Parties to Remove (Stale) Information from the 215 IRRs 217 A third challenge with data contained in IRRs is that it is not 218 possible for IRR operators, and ISP's who use them, to proactively 219 remove (perceived) out-of-date or "stale" resources in an IRR, on 220 behalf of resource holders who may not be diligent in maintaining 221 this information themselves. The reason is that, according to the 222 Resource Policy Specification Language (RPSL) [RFC2622], only the 223 resource holder ('mntner') specified in a 'mnt-by' value field of an 224 RPSL resource is authorized to add, modify or delete their own 225 resources within the IRR. To address this issue, the 'auth-override' 226 mechanism [RFC2725] was later developed that would have enabled a 227 third party to update and/or remove "stale" resources from the IRR. 228 While it is unclear if this was ever implemented or deployed, it does 229 provide language semantics needed to overcome this obstacle. 231 Nevertheless, with such a mechanism in place, there is still a risk 232 that the original RPSL resource holder would not receive 233 notifications (via the 'notify' attribute in various RPSL resources) 234 about the pending or actual removal of a resource from the IRR in 235 time to halt that action if those resources were still being used. 236 In this case, if the removal of a resource was not suspended, it 237 could potentially result in an unintentional denial of service for 238 the RPSL resource holder when, for example, ISP's automatically 239 generated and deployed a new policy based on the newly removed 240 resources from the IRR, thus dropping any reachability announcement 241 for the removed resource in eBGP. 243 4.4. Lack of Authoritative IRR for Resources 245 According to [RFC2622], within an RPSL resource "the source attribute 246 specifies the registry where the object is registered." Note that 247 this source attribute only exists within the RPSL resource itself. 248 Unfortunately, given a specific resource, (e.g.: a specific IPv4 or 249 IPv6 prefix), most of the time it is impossible to tell a priori the 250 authoritative IRR where to query and retrieve an authoritative copy 251 of that resource. 253 This makes it difficult for consumers of data from the IRR to 254 automatically know the authoritative IRR of a resource holder, which 255 will contain their most up-to-date set of resources. This is 256 typically not a problem for an ISP that has a direct (customer) 257 relationship with the resource holder, because the ISP will ask the 258 resource holder which (authoritative) IRR to pull their resources 259 from on, for example, a "Customer BGP Order Form". However, third 260 parties that do not have a direct relationship with the resource 261 holder, have a difficult time attempting to infer the authoritative 262 IRR, preferred by the resource holder, that likely contains the most 263 up-to-date set of resources. As a result, it would be helpful for 264 third parties if there was a robust referral mechanism so that a 265 query to one IRR would be automatically redirected toward the 266 authoritative IRR for the most up-to-date and authoritative copy of 267 that particular resource. This problem is worked around by 268 individual IRR operators storing a local copy of other IRR's 269 resources, through periodic mirroring, which allows the individual 270 IRR to respond to a client's query with all registered instances of a 271 particular IRR resource that exist in both the local IRR and all 272 other IRRs. Of course, the problem with this approach is that an 273 individual IRR operator is under no obligation to mirror all other 274 IRRs and, in practice, some IRRs do not mirror the resources from all 275 other IRRs. This could lead to the false impression that a 276 particular resource is not registered or maintained at a particular 277 IRR. Furthermore, the authentication process of accepting updates by 278 any given IRR may, or may not, be robust enough to overcome 279 impersonation attacks. As a result, there is no rigorous assurance 280 that a mirrored RPSL statement was actually made by the authorized 281 resource holder. 283 4.5. Conclusions with respect to Data in the IRR 285 All of the aforementioned issues related to integrity and accuracy of 286 data within the IRR stem from a distinct lack of resource 287 certification for resources contained within the IRR. Only now is an 288 experimental testbed that reports to provide this function (under the 289 auspices of the Resource PKI [I-D.ietf-sidr-arch]) being formally 290 discussed, which could also aid in certification of resources within 291 the IRR. It should be noted that the RPKI is only currently able to 292 support signing of Route Origin Authorization (ROA) resources that 293 are the equivalent of 'route' resources in the IRR. It is unclear 294 if, in the future, the RPKI will be extended to support additional 295 resources that already exist in the IRR, e.g.: aut-num, as-net, 296 route-set, etc. Finally, a seemingly equivalent resource 297 certification specification for all resources in the IRR has already 298 been developed [RFC2725], however it is unclear how widely it was 299 ever implemented or deployed. 301 5. Operation of the IRR Infrastructure 303 5.1. Replication of Resources Among IRRs 305 Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring 306 (NRTM) protocol to replicate each others contents. However, this 307 protocol has a several weaknesses. Namely, there is no way to 308 validate that the copy of mirror is correct and synchronization 309 issues have often resulted. Furthermore, the NRTM protocol does not 310 employ any security mechanisms. The NRTM protocol relies on a pull 311 mechanism and is generally is configured with a poll interval of 5 to 312 10 minutes. There is currently no mechanism to notify an IRR when an 313 update has occurred in a mirrored IRR so that an immediate update can 314 be made. 316 Some providers employ a process of mirroring an instance of an IRR 317 that involves downloading a flat text file copy of the IRR that is 318 made available via FTP. These FTP files are exported at regular 319 intervals of typically anywhere between 2 and 24 hours by the IRRs. 320 When a provider fetches those text files, it will process them to 321 identify any updates and reflect changes within its own internally 322 maintained database. The use of an internally maintained database is 323 out-of-scope of this document, but is generally used to assist with 324 more straightforward access to or modification of data by the IRR 325 operator. Providers typically employ a 24 hour cycle to pull updated 326 resources from IRRs. Thus, depending on when resource holders 327 submitted their changes to an IRR, it may take up to 24 hours for 328 those changes to be reflected in their policy configurations. In 329 practice, it appears that the RPKI will also employ a 24 hour cycle 330 whereby changes in resources are pushed out to other RPKI caches 331 [REF?]. 333 IRRs originated from Section 7 of [RFC1787], specifically: "The scale 334 of the Internet implies that the [routing requirements] information 335 should be distributed." Regardless, the practical effect of an 336 organization maintaining its own local cache of IRR resources is an 337 increase in resource resiliency (due to multiple copies of the same 338 resource being geographically distributed), a reduction in query time 339 for resources and, likely, a reduction in bandwidth consumption and 340 associated costs. This is particularly beneficial when, for example, 341 an ISP is evaluating resources in an IRR just to determine if there 342 are any modifications to those resources that will ultimately be 343 reflected in a new routing policy that will get propagated to (Edge) 344 routers in the ISP's network. Cache locality results in reduced 345 bandwidth utilization for each round trip. 347 On the other hand, it is unclear from where the current provider 348 replication interval of 24 hours originated or even whether it still 349 provides enough freshness in the face of available resources, 350 particularly in today's environment where a typical IRR system 351 consists of a (multi-core) multi-Ghz CPU connected to a network via a 352 physical connection of 100 Mbps or, more likely, higher bandwidth. 353 In addition, it can be observed that the most common circuit size 354 used by ISP's is now 10 Gbps, thus eliminating bandwidth as a 355 significant factor in the transfer of data between IRRs. 356 Furthermore, it should be noted that Merit's Internet Routing 357 Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default 358 for "irr_mirror_interval". 360 Lastly, it should be noted that [RFC2769], Routing Policy System 361 Replication, attempted to offer a more methodical solution for 362 distributed replication of resources between IRRs. It is unclear why 363 this RFC failed to gain traction, but it is suspected that this was 364 due to that specification's reliance on [RFC2725], Routing Policy 365 System Security, that addressed "the need to assure integrity of the 366 data by providing an authentication and authorization model." 368 5.2. Updating Routing Policies from Updated IRR Resources 370 Ultimately, the length of time it takes to replicate resources among 371 IRRs is, generally, the dominant factor in reflecting changes to 372 resources in policy that is eventually applied within the Control 373 Plane of routers. The length of time to update network elements will 374 vary considerably depending on the size of the ISP and the number of 375 IRR resources that were updated during any given interval. However, 376 there are a variety of common techniques, that are outside the scope 377 of this document, that allow for this automated process to be 378 optimized to considerably reduce the length of time it takes to 379 update policies in the ISP's network. 381 An ISP will begin the process of updating the policy in their 382 network, by first fetching IRR resources associated with, for 383 example, a customer ASN attached to their network. Next, the ISP 384 constructs a new policy associated to that customer and then 385 evaluates if that new policy is different from existing policy 386 associated with that same customer. If there are no changes between 387 the new and existing policy associated with that customer, then the 388 ISP does not make any changes to the policy in their routers specific 389 to that customer. On the other hand, if the new policy does reflect 390 changes from the existing policy for that customer, then the ISP 391 begins a process of uploading the new policy to the routers attached 392 to that customer. 394 The process of constructing a new policy involves use of a set of 395 programs, e.g.: IRRtoolset, that performs recursive expansion of an 396 RPSL aut-num resource, that comprises an arbitrary combination of 397 other RPSL aut-num, as-set, route and route-set resources, according 398 to procedures defined by RPSL. The end result of this process is, 399 traditionally, a router vendor dependent configuration snippet that 400 defines the routing policy for that customer. This routing policy 401 may consist of the set of IPv4 or IPv6 prefixes, associated prefix 402 lengths and AS_PATH's that are supposed to be accepted from a 403 customer's eBGP session. However, if indicated in the appropriate 404 RPSL resource, the policy may also set certain BGP Attributes, such 405 as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the 406 incoming eBGP session from the customer or on static routes that are 407 originated by the resource holder. 409 An ISP's customers may not adequately plan for pre-planned 410 maintenance or, more likely, need to rapidly begin announcing a new 411 IP prefix as a result of, for example, an emergency turn-up of the 412 ISP customer's new downstream customer. Unfortunately, the routine, 413 automated process employed by the ISP means that they may not begin 414 updating their routing policy on their network for up to 24 hours, 415 because the ISP or the IRRs the ISP uses might only mirror changes to 416 IRR resources once every 24 hours. The time interval for the 417 routine/automated process is not responsive to the needs of directly 418 paying customer(s) who need rapid changes in their policy in rare 419 situations. In these situations, when a customer has an urgent need 420 for updates to take affect immediately, they will call up the Network 421 Operations Center (NOC) of their ISP and request that the ISP 422 immediately fetch new IRR objects and push those changes out to their 423 network. This is often accomplished in as little as five minutes 424 from the time a customer contacts their ISP's NOC to the time a new 425 filtering policy is pushed out to the PE routers that are attached to 426 that customer's Attachment Circuits (AC's). It is conceivable that 427 some ISPs automate this using out-of-band mechanisms as well, 428 although the authors are unaware of any existing mechanisms that 429 support this. 431 Ultimately, the aforementioned latency with respect to "emergency 432 changes" in IRR resources that need to be reflected in near-real-time 433 in the network is compounded if the IRR resources were being used by 434 third party ISP's to perform filtering on their peering circuits, 435 where typically no such policies are employed today for this very 436 reason. It is likely that the length of time at which IRRs mirror 437 changes will have to be dramatically reduced with a corresponding 438 reduction in time at the ISP's that, in turn, need to evaluate 439 whether changes in a set of IRR resources need to get reflected in 440 updated router policies that will get pushed out to ASBR's, connected 441 to peering circuits, on their network. 443 6. Historical BGP Protocol Limitations 445 As mentioned previously, after a resource holder made changes to 446 their resources in an IRR, those changes would automatically be 447 distributed to other IRRs, ISPs would then learn of those changes, 448 generate a new BGP policies, and then apply those to the appropriate 449 subset of routers in their ASes. However, in the past, one 450 additional step is necessary in order to have any of those new BGP 451 policies take effect in the Control Plane and to allow/deny the 452 updated resource from a customer to their ISP and from their 453 immediately upstream ISP to the ISP's peers. It was necessary (often 454 manually) to actually induce BGP on each router to apply the new 455 policy within the Control Plane, thus learning of a newly announced/ 456 changed IP prefix (or, dropping a deleted IP prefix). Unfortunately, 457 most of these methods were not only highly operationally impactful, 458 but also affected traffic forwarding to IP destinations that were 459 unrelated to the most recent changes to the BGP policy. 461 Historically, a customer would have to (re-)announce the new IP 462 prefix toward their ISP, but only after the ISP had placed the new 463 BGP policies into affect. Alternatively, the ISP would have to reset 464 the entire PE-CE eBGP session either by: a) bouncing the entire 465 interface toward the customer, (e.g.: shutdown/no shutdown); or, b) 466 clearing the eBGP session toward the customer, (e.g.: clear ip bgp 467 neighbor >IP address of CE router<). The latter two cases were, of 468 course, the most highly impactful and thus could generally only be 469 performed off-hours during a maintenance window. 471 Once the new IP prefix has been successfully announced by the 472 customer and permitted by the newly updated policy at the ISP's PE's 473 (attached to that customer), it would be propagated to that ISP's 474 ASBR's, attached to peers, at the perimeter of the ISP network. 475 Unfortunately, if those peers had either not yet learned of the 476 changes to resources in the IRR or pushed out new BGP policies (and, 477 reset their BGP sessions immediately afterward) incorporating those 478 changes, then the newly announced route would also get dropped at the 479 ingress ASBR's of the peers. 481 Ultimately, either of the two scenarios above further lengthen the 482 effective time it would take for changes in IRR resources to take 483 affect within BGP in the network. Fortunately, BGP has been enhanced 484 over the last several years in order that changes within BGP policy 485 will take affect without requiring a service impacting reset of BGP 486 sessions. Specifically, BGP soft-reconfiguration [REF?] and, later, 487 Route Refresh Capability for BGP-4 [RFC2918] were developed so that 488 ISPs, or their customers, could induce BGP to apply a new policy 489 while leaving both the existing eBGP session active as well as 490 (unaffected) routes active in both the Loc-RIB and, more importantly, 491 FIB of the router. Thus, using either of these mechanisms, an ISP or 492 its peers currently will deploy a newly generated BGP policy, based 493 on changes to resources within the IRR, and immediately trigger a 494 non-service impacting notification to the BGP process to have those 495 changes take affect in their Control Plane, either allowing a new IP 496 prefix to be announced or an old IP prefix to be dropped. This 497 dramatically reduces the length of time after changes are propagated 498 throughout the IRRs to when those changes are actually operational 499 within BGP policy in an ISP's network. 501 7. Historical Limitations of Routers 503 7.1. Incremental Updates to Policy on Routers 505 Routers in the mid 1990's rarely supported incrementally updatable 506 prefix filters for BGP, and therefore, if new information was 507 received from a policy or internal configuration database that would 508 impact a policy applied to a given eBGP peer, the entire prefix list 509 or access list would need to be deleted and rewritten, compiled, and 510 installed. This was very tedious and commonly led to leaked routes 511 during the time when the policy was being rewritten, compiled, and 512 applied on a router. Furthermore, application of a new policy would 513 not automatically result in new ingress or egress reachability 514 advertisements, from that new policy, because routers at the time 515 would require a reset of the eBGP sessions for routing information to 516 be evaluated by the new policy. Of course, resetting of an eBGP 517 session had implications on traffic forwarding during the time the 518 eBGP session was reestablished and new routing information was 519 learned. 521 Routers now support the ability to perform incremental, and in situ, 522 updates to filter lists consisting of IP prefixes and/or AS_PATH's 523 that are used within an ingress or egress BGP policy. In addition, 524 routers also can apply those incremental updates to policy, with no 525 traffic disruption, using BGP soft-reconfiguration or BGP Route 526 Refresh, as discussed in the previous section. 528 7.2. Storage Requirements for Policy on Routers 530 Historically, routers had very limited storage capacity and would 531 have difficulty in storing an extremely large BGP policy on-board. 532 This was typically the result of router hardware vendors using an 533 extremely limited amount of NVRAM for storage of router 534 configurations. 536 Another challenge with historical router hardware was that writing to 537 NVRAM was extremely slow. Thus, when the router configuration had 538 changed as a result of, for example, updating a BGP policy to 539 accommodate changes in IRR resources, this would result in extremely 540 long times to write out these configuration changes and, sometimes, 541 due to bugs would result in loss of protocol keep-alives, thus 542 causing an impact to routing or forwarding of packets through the 543 platform. 545 The above limitations have largely been resolved with more modern 546 equipment from the last few years shipping with increasing amounts of 547 non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk 548 Drives or Solid State Disk Drives. 550 7.3. Updating Configuration on Routers 552 Historically, there has not been a standardized network configuration 553 modeling language or an associated method to update router 554 configurations. When an ISP detected a change in resources within 555 the IRR, it would fashion a router vendor dependent BGP policy and 556 upload that to the router usually via the following method. 558 First, an updated BGP policy configuration 'snippet' is generated via 559 processes running on an offline server. Next, the operator uses 560 either telnet or SSH to login to the CLI of a target router and issue 561 router vendor dependent CLI commands that will trigger the target 562 router to fetch the new configuration snippet via TFTP, FTP or Secure 563 Copy (SCP) stored on the offline server. The target router will then 564 perform syntax checking on that configuration snippet and, if that 565 passes, merge that configuration snippet into the running 566 configuration of the router's Control Software. At this point, the 567 new BGP policy configuration 'snippet' is active within the Control 568 Plane of the router. One last step remains, which is the operator 569 will issue a CLI command to induce the router to perform a "soft 570 reset", via BGP soft-reconfiguration or BGP Route Refresh, of the 571 associated BGP session in order to trigger the router to apply the 572 new policy to routes learned from that BGP session without disrupting 573 traffic forwarding. 575 More recently, operators have the ability to use NETCONF/SSH (or, 576 TLS) from an offline server to push a BGP configuration 'snippet' 577 from an offline server toward a target router that has that 578 capability. However, this activity is still dependent on generating, 579 via the offline server, a router vendor dependent XML configuration 580 snippet that would get uploaded via SSH or TLS to the target router. 582 In the future, the ability to upload new Route Origin Authorization 583 (ROA) information may be provided from the RPKI to routers via the 584 RPKI-RTR [I-D.ietf-sidr-rpki-rtr] protocol. However, this will not 585 allow operators the ability to upload other configuration information 586 such as BGP policy information, such as AS_PATH's, BGP communities, 587 etc. that might be associated with that ROA information, like they 588 can from IRR generated BGP policies. 590 8. Security Considerations 592 9. IANA Considerations 594 10. Acknowledgements 596 TBD. 598 11. Informative References 600 [I-D.ietf-sidr-arch] 601 Lepinski, M. and S. Kent, "An Infrastructure to Support 602 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 603 progress), May 2011. 605 [I-D.ietf-sidr-rpki-rtr] 606 Bush, R. and R. Austein, "The RPKI/Router Protocol", 607 draft-ietf-sidr-rpki-rtr-20 (work in progress), 608 November 2011. 610 [MERIT-IRRD] 611 Merit, "IRRd - Internet Routing Registry Daemon", 612 http://www.irrd.net. 614 [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", 615 RFC 1787, April 1995. 617 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 618 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 619 "Routing Policy Specification Language (RPSL)", RFC 2622, 620 June 1999. 622 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 623 Murphy, "Routing Policy System Security", RFC 2725, 624 December 1999. 626 [RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. 627 Meyer, "Routing Policy System Replication", RFC 2769, 628 February 2000. 630 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 631 September 2000. 633 Authors' Addresses 635 Danny McPherson 636 Verisign, Inc. 638 Email: dmcpherson@verisign.com 640 Shane Amante 641 Level 3 Communications 642 1025 Eldorado Blvd 643 Broomfield, CO 80021 644 USA 646 Email: shane@level3.net 648 Eric Osterweil 649 Verisign, Inc. 651 Email: eosterweil@verisign.com 652 Larry J. Blunk 653 Merit Network, Inc. 655 Email: ljb@merit.edu