idnits 2.17.1 draft-fmejia-opsec-origin-a-country-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2015) is 3341 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Mejia, Ed. 3 Internet-Draft AEPROVI 4 Intended status: Informational R. Gagliano 5 Expires: September 4, 2015 A. Retana 6 Cisco Systems 7 C. Martinez 8 G. Rada 9 LACNIC 10 March 3, 2015 12 Implementing RPKI-based origin validation one country at a time. The 13 Ecuadorian case study. 14 draft-fmejia-opsec-origin-a-country-02 16 Abstract 18 One possible deployment strategy for BGP origin validation based on 19 the Resource Public Key Infrastructure (RPKI) is the construction of 20 islands of trust. This document describes the authors' experience 21 deploying and maintaining a BGP origin validation island of trust in 22 Ecuador. 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 4, 2015. 41 Copyright Notice 43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Policer Network . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. The resource holders . . . . . . . . . . . . . . . . . . 4 61 1.3. RPKI certificate authorities and repository . . . . . . . 5 62 1.4. The technical support . . . . . . . . . . . . . . . . . 5 63 2. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. RPKI-based origin validation support . . . . . . . . . . 6 66 3.2. Deploying a RPKI cache into the network . . . . . . . . . 7 67 3.3. Populating the RPKI database . . . . . . . . . . . . . . 7 68 3.4. Action to take with NotFound and Invalid prefixes . . . . 8 69 4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. RPKI Validation servers . . . . . . . . . . . . . . . . . 9 71 4.2. Origin validation setting . . . . . . . . . . . . . . . . 10 72 5. Training and RPKI signing event . . . . . . . . . . . . . . . 11 73 6. Outcome and post-event activities . . . . . . . . . . . . . . 11 74 7. Lessons learned and best practices . . . . . . . . . . . . . 12 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 78 11. Informative References . . . . . . . . . . . . . . . . . . . 13 79 Appendix A. Router configuration templates for Cisco IOS . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 BGP origin validation based on RPKI [RFC6811] is in early stages of 85 deployment. As with other new technologies, there are impediments to 86 its global adoption as its full value is not yet perceived. 87 Particularly, RPKI based origin validation involves on one side the 88 creation of a large enough set of signed objects and on the other 89 side the application of network policies based on these signed 90 objects by network operators. An operator that does not see a large 91 enough set of signed objects in the RPKI repository system is not 92 encouraged to implement these set of policies. Conversely, IP 93 address space resource holders that are not required by network 94 operators (i.e. transit providers, peers or operators community in 95 general) to create and mantain their RPKI objects have little 96 incentive to do so. 98 To overcome this bootstrap problem, it is necessary to create a 99 success story that brings enough value to both: network operators and 100 resource holders. Moreover, one possible strategy for the adoption 101 of a security technology is the creation of islands of trust where 102 the technology is fully deployed in a reduced environment. In this 103 direction, some organizations carried forward a full implementation 104 of an island of trust in Ecuador. This was a multi stakeholder 105 project where each party (resource holders, an Internet Exchange 106 Point manager, a Regional Internet Registry and an equipment 107 manufacturer) contributed to its success. 109 This document describes the experience of implementing RPKI-based 110 origin validation in Ecuador and it is expected to be an useful guide 111 to start other similar projects. 113 Below, it is described the different roles in the project and the 114 involved parties. 116 1.1. Policer Network 118 In this document, the "Policer Network" is the networking 119 infrastructure where the origin validation based on RPKI will be 120 deployed to apply polices on BGP announcements. NAP.EC (www.nap.ec) 121 was selected for this role. 123 NAP.EC is the Internet Exchange Point (IXP) in Ecuador with two 124 Points of Presence (POPs): Quito (UIO) and Guayaquil (GYE). It has a 125 BGP route-server in each location with a mandatory multilateral 126 routing policy (i.e. all participants have a BGP session to the 127 route-server). Each location uses a different IP address block and 128 Autonomous System Number (ASN). NAP.EC is a meeting point where many 129 organizations (Internet Service Providers, content providers, root 130 servers, etc.) exchange routing information. 132 The participants connected to NAP.EC announce almost 100% of the 133 total address space used in Ecuador (be believe it is 100% but we 134 cannot be certain though). In some cases they announce their own 135 address space and in some cases they are transit providers for their 136 customers' resources. 138 AEPROVI (www.aeprovi.org.ec) manages the NAP.EC infrastructure. It 139 is a non-profit organization, based on membership and brings together 140 around 30 Ecuadorian ICT-related companies. AEPROVI also has an 141 excellent reputation as an innovator in the local networking 142 community thanks to projects such as IPv6 adoption and CDN cache 143 servers hosting. These projects have given the local community 144 concrete value and have build the trust on the team that manages the 145 local IXP. 147 Thanks to this trust, and to the fact that all local BGP 148 announcements are performed through the route servers, NAP.EC is 149 uniquely positioned to become the "policer network" for this project. 150 At the same time, it can be said that implementing origin validation 151 at the NAP.EC route servers is equivalent to implementing it for all 152 inter-domain routing in the country. 154 1.2. The resource holders 156 In this document, an organization which operates their own IP 157 prefixes is called resource holder or simply the holder. They may 158 have resources allocated/assigned from a Regional Internet Registry 159 (RIR) and/or legacy resources (if the allocation was done before RIR 160 formation). Resource holders are responsible for creating the RPKI 161 signed objects for this project. 163 NAP.EC routing tables involve a number of holders, including 164 organizations like Internet Service Providers, content providers, 165 universities, .ec domain administrator and root servers. Most of 166 them are Ecuadorian companies and have received IP resources only 167 from LACNIC, but some have both RIR and legacy resources. Moreover, 168 a few holders are foreign companies and their resources are legacy or 169 from other RIRs (e.g. root servers and content providers). 171 Not all resource holders are directly connected to the NAP.EC fabric; 172 some have IP address resources but not an ASN and some others are 173 small networks that receive traffic from other bigger networks. In 174 this case their IP address prefixes are announced by their transit 175 providers. One of the main challenges for this project was to 176 identify all the resource holders that needed to be contacted and to 177 encourage network administrators from these organizations to 178 participate. 180 In addition, some resource holders are part of a larger (and 181 sometimes international) organization, with strong change management 182 processes. This means that any change on their configurations needed 183 to be planned ahead of time and consulted outside of the country. 185 In NAP.EC - UIO, the routing table includes prefixes used in Ecuador 186 and other countries. 188 In NAP.EC - GYE, the routing table includes prefixes from companies 189 operating only in Ecuador. 191 For the project, the target was limited to prefixes used in Ecuador 192 by Ecuadorian holders that had received resources from LACNIC until 193 mid-2013. 195 1.3. RPKI certificate authorities and repository 197 The five Regional Internet Registries (RIRs) have a critical role in 198 the RPKI trust model since they manage the trust anchors of the RPKI 199 hierarchic design. Additionally, due to some reasons (e.g. 200 economics, skills) the scenario where the Certification Authority 201 (CA) certificate is hosted by a RIR will be the most popular for a 202 long time, in which case, RIR's online software tools to manage RPKI 203 objects are imperative. 205 The RIR-hosted RPKI CA model was used for this project. Local RPKI 206 validation servers (validation and cache) were locally deployed. 207 This means that all resource holders had to create and manage their 208 RPKI signed objects using the online tools implemented by LACNIC and 209 that the local validation servers retrieve these objects from the 210 RIR's public global repositories. No local RPKI CA nor repository 211 were configured. 213 LACNIC also runs a RPKI testbed (test CA with correspondent GUI and 214 Trust Anchor material). This infrastructure was used during the 215 training activity. 217 1.4. The technical support 219 RPKI and origin validation are in the early stage of deployment. Few 220 people have full knowledge about its RFCs, the implementation support 221 in different routers and the maintenance of RPKI signed objects. To 222 involve trained people and train new ones is very important. 224 People from an equipment manufacturer (Cisco) contributed with 225 support in the startup stage and to train the holders' staff. 226 LACNIC's staff contributed developing new online RPKI tools and 227 training about how to use them. 229 2. Objective 231 Considering all the definitions given during the introduction and 232 after several discussions through face and online meetings among the 233 involved parties, the following objective was agreed on: 235 "Deploy RPKI-based BGP origin validation in NAP.EC's route servers. 236 For the success of the project, 80% of the Ecuadorian prefixes (both 237 IPv4 and IPv6) received by those routers should have a valid origin." 239 In order to monitor the progress, NAP.EC - GYE was taken as reference 240 because NAP.EC - UIO had non-Ecuadorian prefixes announced. 242 3. Planning 244 The project started with an initial idea from a very reduced number 245 of enthusiasts that identified a suitable network (the island of 246 trust), involved the appropriate organizations and set milestones in 247 order to carry forward a full implementation of the technology. Into 248 the process, all parties identified the gaps and proposed solutions 249 to overcome them. 251 One point that it was wanted to guarantee is that we would be able to 252 create the appropriate "buzz" around the project. So, a 253 communication strategy should not be overlooked. In this case, 254 LACNIC and AEPROVI signed a MoU in April 2013 and all parties 255 (LACNIC, AEPROVI and Cisco) announced the project and issued a press 256 release at the LACNIC event in May 2013. 258 Some points that required specific discussion by the core team 259 included: 261 1. RPKI-based origin validation support in the route-servers 262 equipments 264 2. How to deploy a RPKI cache into the Network 266 3. How to populate the RPKI database with the correct and necessary 267 information 269 4. Action to take with NotFound and Invalid prefixes 271 3.1. RPKI-based origin validation support 273 NAP.EC uses Cisco equipment. The project started with the initial 274 idea of to implement origin validation into existing routers used as 275 route servers, simply after a software update or upgrade. However, 276 the vendor had no plans to support it in the existing platform. 277 AEPROVI had future plans to carry forward a routers renewal, then 278 this issue was overcame but it stopped the project for some time. 279 Describing the equipment renewal process is beyond the scope of this 280 document. 282 For Cisco equipment, the vendor has made available some online 283 software tools to check the support. About origin validation, the 284 routers must support: RTR protocol [RFC6810] and RPKI-based origin 285 validation [RFC6811]. Moreover, among other things, four octects ASN 286 support [RFC6793] and IPv6 routing support ([RFC2545] and some 287 others) are mandatory in NAP.EC. 289 The selected routers were two Cisco ASR-1000 series routers (one for 290 Quito and other for Guayaquil). 292 3.2. Deploying a RPKI cache into the network 294 Based on available resources and existing skills, it was decided to 295 use Virtual Machines (VM) as RPKI caches, which would run GNU Linux. 297 The validating software is in the early stages of its development and 298 there could be bugs or reliability problems, so it was decided using 299 two different packages (processes) in each VM. 301 To ensure high availability, it was decided to deploy two VMs, each 302 one in different host server. 304 There are no servers in Guayaquil, therefore both VMs would be in 305 Quito within the NAP.EC management network and connect via the RTR 306 protocol to the route-servers located in Quito and Guayaquil. 308 Additionally, the firewall rules allow RTR connections from the 309 NAP.EC LANs to the RPKI validator servers in order to facilitate 310 participants to perform origin validation in their edge equipments 311 (if they wish to in the future). 313 3.3. Populating the RPKI database 315 The IP resource holders must create all needed RPKI data for the 316 project, at least certificates and Route Origin Authorizations 317 (ROAs). Moreover, the technical staff needed training about RPKI and 318 origin validation because it is a new technology. Accordingly, a 319 reasonable method to achieve it should be contrived. 321 It was decided to organize an event with two objectives: training and 322 RPKI object signing. One key planning activity was to create the 323 list of participants and to make sure that at least one participant 324 per network had the authentication credentials to the LACNIC system 325 to create its RPKI signed objects. 327 The target community was limited to Ecuadorian organizations that had 328 received IP resources from LACNIC until mid-2013. That meant around 329 fifty (50) organizations including Internet Services Providers, 330 universities, banks, etc., or expressing it in prefixes: around 8600 331 IPv4 and 60 IPv6 blocks. 333 Some weeks before the deployment, there was informal dissemination 334 meetings between the NAP.EC administrator and the participants. The 335 project milestones were reported and the attendees received 336 information about RPKI and origin validation for the first time. A 337 complete training was offered as a project milestone in the next few 338 weeks. 340 All organizations were contacted and received an invitation to the 341 event. More information about this can be found in Section 5. 343 3.4. Action to take with NotFound and Invalid prefixes 345 Despite the efforts, the RPKI database information may be incomplete, 346 therefore the routing tables often will have NotFound prefixes. 347 Moreover, it is needed some time after the first contact with RPKI- 348 based origin validation technology to fix possible errors (e.g. 349 invalid prefixes) and to assess the impact. A strict policy of 350 dropping prefixes did not seem convenient as a starting point for the 351 project. 353 It was decided that NAP.EC proceeds as follows: 355 - At the beginning, the NAP.EC's routers only would monitor the RPKI 356 origin state of prefixes without action. 358 - In the near future, NAP.EC administration might change the action 359 based on results of the signing-party event and community 360 consensus. 362 As part of the second stage, some days after the signing event, each 363 prefix is being marked with a BGP community to identify its RPKI 364 origin state, sending that information to the participants. 366 Finally, some months later, a date was set to begin applying a strict 367 policy. The policy was defined as follows: dropping Invalid prefixes 368 and setting a lower local preference for NotFound prefixes. 370 4. Deployment 372 Following is the NAP.EC topology during the deployment: 374 ASN Y ASN Y 375 | | 376 ---------------- ---------------- 377 ASN X -- | SWITCH UIO |----- AS 27814 -------| SWITCH GYE |---ASN Z 378 ---------------- | ---------------- 379 | | | 380 ---------------- NAP.EC ---------------- 381 | AS 52482 | Management | AS 52483 | 382 | Route Server | Network | Route Server | 383 | UIO | | | GYE | 384 ---------------- | ---------------- 386 RPKI Validation servers 387 (2 virtual server at UIO) 389 4.1. RPKI Validation servers 391 A virtual machine (named VM1) on VMware ESXi was deployed, running 392 GNU Linux, Centos distribution. The other one (named VM2) was cloned 393 from this one. 395 Each virtual machine has access to the Internet through 1 (one) 396 ethernet interface with a public IPv4 address within the same subnet 397 like this: 192.0.2.2/27 for VM1, 192.0.2.3/27 for VM2 and 398 192.0.2.1/27 for network gateway. 400 The 192.0.2.0/27 network is within AS 27814. AS 27814 contains 401 NAP.EC monitoring equipment (among other things) and it is connected 402 to NAP.EC - Quito and NAP.EC - Guayaquil. 404 Each VM has the following packages (installation and configuration 405 guides of these packages are beyond the scope of this document): 407 - ntpd (as NTP client) 409 - iptables (as firewall) 411 - apache (as web server) 413 - validating software from RIPE (http://www.ripe.net/lir-services/ 414 resource-management/certification/tools-and-resources) 416 - validating software from the rpki.net project 417 (http://rpki.net/wiki/doc/RPKI/Installation) 419 Each validating software was setup on a different port: 421 - validating software from RIPE, port 65001, 422 - validating software from the rpki.net project, port 65002. 424 Each validating software has a monitoring web page, each one was 425 configured on different port: 427 - RIPE software, port 65081, 429 - rpki.net software, port 65082. 431 4.2. Origin validation setting 433 Since the routers renewal, NAP.EC - Quito and NAP.EC - Guayaquil have 434 each one a Cisco ASR-1000 series router as route server. These 435 routers have IOS-XE version 3 which runs a process with IOS version 436 15. 438 First, it is required to configure communication via RTR protocol 439 between the routers and the RPKI validation servers (caches). In 440 this step, the necessary data are: IP addresses and service ports of 441 the caches and the time which the router will re-query the cache 442 (refresh time). Currently, RPKI information does not change quickly, 443 therefore 600 seconds (10 minutes) may be considered enough for 444 refresh time. 446 Cisco IOS 15 drops Invalid prefixes by default, but there is a 447 command to avoid this behavior (ibgp bestpath prefix-validate allow- 448 invalid). This must be applied while the policy is no action. 450 Later, a route-map is required to configure any action as applying 451 different BGP local preference or marking each prefix with a BGP 452 community based on its RPKI origin state (also send-community option 453 must be enabled within the BGP session configuration): 455 The following community assignment policy was applied: 457 - :21 --> Valid origin 459 - :22 --> NotFound origin 461 - :23 --> Invalid origin 463 Where equals: 465 - 52482 for NAP.EC - Quito, or 467 - 52483 for NAP.EC - Guayaquil. 469 The template used in NAP.EC is in Appendix A. 471 5. Training and RPKI signing event 473 The event was called "Seminario sobre seguridad en el encaminamiento 474 de Internet: BGP RPKI - Validacion de origen" and was scheduled for 475 September 4-5, 2013. The agenda included theoretical and practical 476 training, plus two time slots to sign RPKI objects: one at the end of 477 the first day and other one during the second day. 479 Lack of training materials was a issue to overcome during preparatory 480 work of the event. Some necessary activities were: 482 - The instructors (four people) prepared materials to cover topics 483 such as BGP, RPKI, origin validation and the new NAP.EC platform. 485 - LACNIC's staff developed two new on-line tools: RPKI ROA wizard 486 (http://tools.labs.lacnic.net/roa-wizard/) and RPKI announcement 487 (http://tools.labs.lacnic.net/announcement/), further improved the 488 demo environment of the RPKI system 489 (http://rpkidemo.labs.lacnic.net/). 491 - Cisco's staff implemented a temporary virtualized network with 492 many routers supporting RPKI and origin validation. 494 The event took place in a hotel and had Internet to access the 495 training tools and the real LACNIC's hosted RPKI system. 497 Not all organizations sent a representative. The attendance 498 represented around 80% of the target prefixes. 500 6. Outcome and post-event activities 502 Before the event, less 1% of the Ecuadorian prefixes were signed. At 503 the start of the second day, less than 20% of the Ecuadorian prefixes 504 were covered by a ROA. At the end of the event, around 80% of the 505 Ecuadorian prefixes had a RPKI origin state as Valid. 507 MRTG graphs were implemented to monitor the amount of Valid, NotFound 508 and Invalid prefixes after the event. 510 Feedback was received from attendees before closing the event. Some 511 people recommended applying an acceptable policy in order do not 512 waste the successful effort. 514 A few days after the event, some non-attending organizations were 515 contacted by the NAP.EC administrator and meetings were coordinated 516 for ROA creation. After these activities, almost 100% of Ecuadorian 517 prefixes are covered for a ROA. 519 Communication activities performed after the event included: 521 - This document and presentation at relevant IETF Working Groups. 523 - Presentation at IEPG, LACNIC and other NOG events. 525 - Publication at tech sites. 527 - Communication to local telecommunications regulator. 529 - Document and presentation at CITEL (Organization of American 530 States). 532 - Blogging and social media in relevant platforms. 534 As subsequent operational tasks, the following are necessary: 536 - Updating of validating software. 538 - Permanent monitoring the origin state of prefixes. 540 - Alerting about Invalid prefixes. 542 7. Lessons learned and best practices 544 - Implementation support needs to be verified in all target 545 platforms. 547 - The IP resource holders community need RPKI-based origin 548 validation training. 550 - Initial work to have the "right people" in the room is a key to 551 success for the RPKI signing party. Particularly, operators need 552 to have access to their RIR account. 554 - One day for a RPKI signing party is insufficient, two days is a 555 better practice. The participants may not be confident about 556 their skills or may need further authorization (people need to 557 sleep over what they learned the first day). 559 - The event was a great opportunity to assemble the local community, 560 particularly resource holders that had no previous participation 561 at the local IXP. 563 - Post event communication needs to be discussed ahead of time. 565 - Operators are less conservative than original though by organizers 566 and once RPKI local space was full, support for removing invalid 567 prefixes was unanimous. 569 - From now on, when a new ISP wants to join NAP.EC, it receives 570 information about RPKI-based origin validation and it is invited 571 to create its ROAs. 573 8. IANA Considerations 575 No IANA requirements 577 9. Security Considerations 579 This document describes the experience of implementing a BGP origin 580 validation island of trust in Ecuador. The actions taken are 581 explicitly to be able to validate the origin in a BGP advertisement. 582 There were no security-related issues identified during the 583 deployment. 585 10. Acknowledgements 587 The authors wish to thank: 589 - all attendees at the training and RPKI signing event, without them 590 this would not have happened. 592 - AEPROVI, LACNIC and Cisco for supporting the project. 594 - Arturo Servin for supporting the project from the start. 596 - Francisco Balarezo, Andres Piazza, Nicolas Fiumarelli and Chip 597 Sharp as well as ISOC and Andean-Trade. 599 11. Informative References 601 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 602 Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 603 1999. 605 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 606 Autonomous System (AS) Number Space", RFC 6793, December 607 2012. 609 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 610 Infrastructure (RPKI) to Router Protocol", RFC 6810, 611 January 2013. 613 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 614 Austein, "BGP Prefix Origin Validation", RFC 6811, January 615 2013. 617 Appendix A. Router configuration templates for Cisco IOS 619 TEMPLATE 1 621 Policy: Only marking prefixes based on RPKI origin state. 623 router bgp 625 bgp rpki server tcp 192.0.2.2 port 65001 refresh 600 627 bgp rpki server tcp 192.0.2.2 port 65002 refresh 600 629 bgp rpki server tcp 192.0.2.3 port 65001 refresh 600 631 bgp rpki server tcp 192.0.2.3 port 65002 refresh 600 633 ! 635 neighbor remote-as 637 neighbor version 4 639 ! 641 neighbor remote-as 643 neighbor version 4 645 ! 647 address-family ipv4 649 bgp bestpath prefix-validate allow-invalid 651 neighbor send-community 653 neighbor route-map in 655 exit-address-family 657 ! 659 address-family ipv6 660 bgp bestpath prefix-validate allow-invalid 662 neighbor send-community 664 neighbor route-map in 666 exit-address-family 668 ! 670 ! 672 ip bgp-community new-format 674 ! 676 ! 678 route-map permit 10 680 match rpki valid 682 set community :21 684 ! 686 route-map permit 20 688 match rpki not-found 690 set community :22 692 ! 694 route-map permit 30 696 match rpki invalid 698 set community :23 700 ! 702 TEMPLATE 2 704 Policy: Dropping Invalid prefixes and setting lower local preference 705 for NotFound prefixes. 707 router bgp 708 bgp rpki server tcp 192.0.2.2 port 65001 refresh 600 710 bgp rpki server tcp 192.0.2.2 port 65002 refresh 600 712 bgp rpki server tcp 192.0.2.3 port 65001 refresh 600 714 bgp rpki server tcp 192.0.2.3 port 65002 refresh 600 716 ! 718 neighbor remote-as 720 neighbor version 4 722 ! 724 neighbor remote-as 726 neighbor version 4 728 ! 730 address-family ipv4 732 neighbor send-community 734 neighbor route-map in 736 exit-address-family 738 ! 740 address-family ipv6 742 neighbor send-community 744 neighbor route-map in 746 exit-address-family 748 ! 750 ! 752 ip bgp-community new-format 754 ! 755 ! 757 route-map permit 10 759 match rpki valid 761 set community :21 763 ! 765 route-map permit 20 767 match rpki not-found 769 set local-preference 50 771 set community :22 773 ! 775 ! 777 Authors' Addresses 779 Fabian Mejia (editor) 780 AEPROVI 781 Av. Republica de El Salvador N34-211 782 Quito 783 EC 785 Email: fabian@aeprovi.org.ec 787 Roque Gagliano 788 Cisco Systems 789 Avenue des Uttins 5 790 Rolle 1180 791 Switzerland 793 Email: rogaglia@cisco.com 794 Alvaro Retana 795 Cisco Systems 796 7025 Kit Creek Rd. 797 Research Triangle Park, NC 27617 798 US 800 Email: aretana@cisco.com 802 Carlos Martinez 803 LACNIC 805 Email: carlos@lacnic.net 807 Gerardo Rada 808 LACNIC