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