Transcription
BGP Origin ValidationISP WorkshopsThese materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International 4.0/)Last updated 8 th May 20221
AcknowledgementspThis material includes valuable contributions by Randy Bush, MarkTinka, Aftab Siddiqui, Tashi Phuntsho, Warrick Mitchell and otherspUse of these materials is encouraged as long as the source is fullyacknowledged and this notice remains in placepBug fixes and improvements are welcomednPlease email workshop (at) bgp4all.comPhilip Smith2
BGP VideospNSRC has produced a library of BGP presentations (including thisone), recorded on video, for the whole community to usenhttps://learn.nsrc.org/bgp3
Validating BGP Route AnnouncementsHow do we know that an AS is permitted to originate theprefix it is originating?p Implicit trust?p Because the Internet Routing Registry says so?pnnpThe Internet Routing Registry (IRR) only documents routingpolicyAnd has a large amount of outdated/incorrect informationIs there something else?nYes: Route Origin Authorisation4
BGP – Why Origin Validation?pPrevent YouTube accident & Far WorsenpPrevents most accidental announcementsnpAlmost every day there is an incident of prefix hijacksomewhere on the Internet“Fat finger”, missing BGP policy configuration, etcDoes not prevent malicious path attacksnnExample: alteration of AS-PATH attribute along theannouncement chainThat requires ‘Path Validation’, using BGPsec
RPKIpRPKI – Resource Public Key InfrastructurenpThe Certificate Infrastructure for origin and path validationWe need to be able to authoritatively prove who owns anIP prefix and which AS(s) may announce itnnPrefix ownership follows the allocation hierarchyIANA RIRs ISPs etc
What is RPKI?pResource Public Key Infrastructure (RPKI)nnpA security framework for verifying the association between resourceholder and their Internet resourcesCreated to address the issues discussed in RFC 4593 “Generic Threats toRouting Protocols” (Oct 2006)Helps to secure Internet routing by validating routesnnnProof that prefix announcements are coming from the legitimate holderof the resourceRFC 6480 – An Infrastructure to Support Secure Internet Routing (Feb2012)RFC 7115 – Origin Validation Operation Based on the Resource PublicKey Infrastructure (RPKI)7
Benefits of RPKI for RoutingpPrevents route hijackingnnpA prefix originated by an AS without authorisationReason: malicious intentPrevents mis-originationnnnA prefix that is mistakenly originated by an AS which does notown itAlso, route leakageReason: configuration mistake / fat finger8
BGP Security (BGPsec)pExtension to BGP that provides improved security for BGProutingnnPublished as RFC8205Not yet deployedImplemented via a new optional non-transitive BGPattribute (BGPsec PATH) that contains a digital signaturep BGPsec supplements BGP origin validationpnAllows routers to generate, propagate, and validate BGP updatemessages with the BGPsec PATH attribute set9
BGPsec ComponentspOrigin ValidationnnpUsing the RPKI to detect and prevent mis-originations of someone else’s prefixes(RFC6483)Implementation started in 2012AS-Path ValidationnnBGPsec has not yet begun deployment (cryptographic computation load)soBGP was one early ite-sobgp-architecture/ (expired)Not standardised or implementedASPA (Autonomous System Provider Authorisation) is the most promising interimstep prior to full BGPsec ietf-sidrops-aspa-verification/
RPKI NomenclaturepIssuing PartynpTrust AnchornpThe authority from which trust is assumed, rather than derived fromintermediates – the root of the treeRelying PartynpThe entity operating as certificate authority (CA)The operator system gathering data from the certificate authority to beused for validationRoute Origin AuthorisationnAn digital object linking an AS number with the IP address space it isauthorised to originate11
Issuing PartyppppInternet Registries (RIR, NIR, Large LIRs)Acts as a Certificate Authority and issues certificates forcustomersProvides a web interface to issue ROAs for customer prefixesPublishes the ROA recordsRIR RPKIEnginerepositoryRIR public repositoryRIR web interface12
Relying Party (RP)IANAAfriNICRepoAPNICRepoARINRepoLACNICRepoRIPE NCCRepoRP Cache software alsoknown as a ValidatorLIR RepoValidatedCacheRPKI-to-RouterProtocol13RP Cache
RPKI Componentsrpki.afrinic.netTrust Anchorrrdp.arin.netTrust Anchorrpki.apnic.netRPKI EngineTrust etNetworkOperatorTrust AnchorWeb interfacerpki.ripe.netTrust AnchorEach of the RIRs publishes their “Trust Anchor Locator” (TAL) – the filethat contains both the URL of the RPKI repository and the public key14
RPKI Service ModelspHosted Model:nThe RIR runs the CA on behalf of its memberspppManage keys, repository, etcGenerate certificates for resource certificationsDelegated Model:nMember becomes the CA, delegated from the parent CA (theRIR)ppnOperates the full RPKI systemSeveral entities now operating delegated CAsCA SoftwarepNLnetLabs Krill: https://www.nlnetlabs.nl/projects/rpki/krill/15
Route Origin Authorisation (ROA)A digital object that contains a list of address prefixesand one AS numberp It is an authority created by a prefix holder to authorisean AS Number to originate one or more specific routeadvertisementsp Publish a ROA using your RIR member portalpnConsult your RIR for how to use their member portal to publishyour ROAs16
Route Origin AuthorisationppA typical ROA would look like 34There can be more than one ROA per address blocknnAllows the operator to originate prefixes from more than one ASCaters for changes in routing policy or prefix origin17
Creating ROAsOnly create ROAs for the aggregate and the exactsubnets expected in the routing tablep Examples:pPrefixMax LengthOrigin ASComments10.10.0.0/16/2465534ROA covers /16 through to /24 – any announcedsubnets to /24 will be Valid if from AS6553410.10.0.0/16/1665534ROA covers only /16 – any announced subnetswill be Invalid10.10.4.0/22/2465534ROA covers this /22 through to /2410.10.32.0/22/2464512Valid ROA covers /22 through to /24announcements from AS6451218
Creating ROAs – Important NotesAlways create ROAs for the aggregate and the individualsubnets being routed in BGPp Example:pnIf creating a ROA for 10.10.0.0/16 and “max prefix” length isset to /16ppThere will only be a valid ROA for 10.10.0.0/16If a subnet of 10.10.0.0/16 is originated, it will be state Invalid19
Creating ROAs – Important NotespAvoid creating ROAs for subnets of an aggregate unless they areactually being actively routednpIf ROA exists, but subnet is not routed, it leaves an opportunity for someone elseto mis-originate the subnet using the valid origin AS, resulting in a sidrops-rpkimaxlen/ hasa good description of the care needed when creating ROAsnRecommendations:ppnnAvoid using maxLength attribute unless in special casesUse minimal ROAs wherever possible – only for prefixes that are actually being announcedAlso a discussion about ROAs for facilitating DDoS ServicesThere is even a strong suggestion that “maxLength” should be deprecated20
Creating ROAs – Important NotespSome current examples of problematic ROAs:nThis means that any and every subnet of 2C0F:F0C8::/32 originated by AS328037is validppnAn attacker can use AS328037 as their origin AS to originate 2C0F:F0C8:A0:/48 to denyservice to that address blockKnown as a validated hijack!This means that any subnet of 1.34.0.0/15 down to a /24 as originated byAS3462 is validpAn attacker can use AS3462 as their origin AS to originate 1.34.10.0/24 to deny service tothat address block21
Creating ROAs: “Validated Hijack”UpstreamGlobal InternetViewerUpstreamAS3462Originator of 1.34.0.0/15with ROA MaxLen of /24Traffic Flow for1.34.10.0/24AttackerUpstreamAS3462Valid ROA for /15 and /24Best path selection: /24preferred over the /15pAttacker: uses target ASas their originOriginates: 1.34.10.0/24If the 1.34.10.0/24 prefix had had no ROA, route origin validation wouldhave dropped the invalid announcement at the upstream AS22
Creating ROAs: pre-RIR Address SpacepSome entities were assigned address space by InterNICnppThis is prior to the existence of the RIRsHow to sign ROAs for these resources?Some RIRs will support the signing of legacy address space ROAsnnnnIf there is documentation proving the holdingIf there is some service agreement for resources allocated by the RIROr by some other arrangementExample, 018/02/APNIC-AR-2017.pdfExample, RIPE n-rpki-for-provider-independent-end-users23
Route Origin ValidationRouter must support RPKIp Checks an RP cache / validatorpnpUses RtR protocol, described in RFC8210Validation returns 3 states:StateDescriptionValidWhen authorisation is found for prefix X comingfrom ASN YInvalidWhen authorisation is found for prefix X but notfrom ASN Y, or not allowable subnet sizeNot FoundWhen no authorisation data is found for prefix X24
Route Origin Validation – AS0pRFC6483 also describes “Disavowal of RoutingOrigination”nnAS 0 has been reserved for network operators and other entitiesto identify non-routed networksWhich means:pp“A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder ofa prefix that the prefix described in the ROA, and any more specific prefix,should not be used in a routing context”Any prefixes with ROA indicating AS0 as the origin ASneed to be droppednIf these prefixes appear with any other origin, their ROAs will beinvalid, achieving this goal25
Route Origin Validation – AS0pPossible use cases of AS0:nnnnInternal use of a prefix that should not appear in the global BGPtableInternet Exchange Point LAN must never appear in the globalBGP tablePrivate Address space (IPv4) and non-Global Unicast space(IPv6)Unassigned address spacepnThis is under discussion within the various RIR policy foraIPv4 and IPv6 address resources which should not appear in theglobal BGP tablepFor example, the special use address space described in RFC689026
Route Origin Validation – AS0pAPNIC & LACNIC have now published their AS0 TALsnOperated separately from the regular rSimply add to the TAL folder in the validator cacheSome examples of AS0 being used today:RPKI/RTR prefix fix Length22 - 2422 - 2224 - 2424 - 2423 - 2422 - 2224 - 2422 - 22Origin-AS0000000027
Route Origin Validation – ImplementationsppppppppppppCisco IOS – available from release 15.2Cisco IOS/XR – available from release 4.3.2Juniper JunOS – available from release 12.2Nokia – available from release R12.0R4Huawei – available from release V800R009C10FRR – available from release 4.0BIRD – available from release 1.6OpenBGPD – available from OpenBSD release 6.4GoBGP – available since 2018VyOS – available from release 1.2.0-RC11Mikrotik ROS – available from release v7Arista EOS – available from release 4.24.0F28
RPKI Validator Caches (1)pNLnet Labs Routinator ckages available for Debian/Ubuntu, RHEL/CentOS & FreeBSD(Can also be built from source)LACNIC/NIC Mexico validator s://nicmx.github.io/FORT-validator/Packages available for Debian/Ubuntu, RHEL/CentOS & FreeBSD(Can also be built from source)29
RPKI Validator Caches entRPKI repository query system (output for OpenBGPD, BIRD, json)For OpenBSD, with ports for Debian/Ubuntu, RHEL/CentOS, FreeBSD, .debian.org/pkg/stayrtrRPKI to Router protocol implementation (input JSON formatted VRP exports)(hard fork of Cloudflare GoRTR)Works on anything Go runs on (?)Note:nRPKI-client and StayRTR are used together30
RPKI Validator Caches ir2No longer maintained:nnDragon Research Labs “rcynic”Cloudflare validator (OctoRPKI/GoRTR)pnStayRTR is a fork of GoRTRRIPE NCC validatorpVersion 2 and 331
Installing a validatorpThree validators are widely usednnnRoutinatorFORTRPKI-client/StayRTRListed in order of ease of installation p For installation details on Ubuntu 20.04pnhttps://bgp4all.com/pfs/hints/rpki32
Installing a validator – RoutinatorpIf using Ubuntu/Debian, then simply use the packagemanager, as r#quick-start-with-debian-andubuntu-packagesIn summary:nnnnnGet the NLnetLabs public keyAdd the repo to the sources listsInstall routinatorInitialiseRun33
Routinator 3000 web interfacepUser interface ofRoutinator accessedby enabling httpoption in the serverconfigurationnListens on port 8323/etc/routinator/routinator.conf34
Installing a validator – FORTpEasiest is to download one of the packages availablenDescribed at n.htmlExample for Ubuntu 20.04:nNote the automatic creation of the systemd entrynThe configuration file is /etc/fort/config.json – set the listening port here (323 by default)n35
Running FORTpOther notes:nnnNeed to refresh the TALs beforestartingNeed to make sure that/var/lib/fort is owned by thefort userOtherwise FORT will crash onstartup with these errors becauseit cannot write there:36
Installing rpki-client (1)prpki-client has no package and will have to be built from scratchnEasiest is to build from the Git lient-portableNote the instructions to get the environment ready:nnnYou will need automake, autoconf, git, libtool, and libexpat-dev to be installed first – use thepackage managerLibreSSL tls is also needed – this is part of OpenBSD but the source will compile on LinuxGet latest reSSL/Unpack and then run:./configure --enable-libtls-onlymakemake install37nWhich will build and install the libtls that rpki-client needs
Installing rpki-client (2)pWith the environment readynnRun “./autogen.sh” inside the rpki-clientdistributionThen run./configure --with-tal-dir /etc/rpki \--with-base-dir /var/lib/rpki-client \--with-output-dir /var/db/rpki-clientnAnd finally build the client by running make38
Running rpki-clientpBefore we install the client we need to add the specific user and group that the clientwill use:sudo groupadd rpki-clientsudo useradd –g rpki-client –s /sbin/nologin –d /nonexistent –c “rpki-client user” rpki-clientpAnd then we can run:sudo make installnpWhich will install the client in /usr/local/sbin and the 4 TALs in /etc/rpki, as well as create the cache andoutput directories neededARIN TAL requires users to read the disclaimer arin.talpNow the client can be run (at the command-line, no daemon)pClient authors recommend running the client hourly by cronnSee https://man.openbsd.org/rpki-client for more information about output options39
Installing StayRTRpStayRTR has no package and willhave to be built from scratchnEasiest is to build from the Git repository:ppYou will also need a working Goenvironmentnphttps://github.com/bgp/stayrtrThe Go site has more information:https://go.dev/doc/installAnd then you can build StayRTR:cd stayrtrmake build-stayrtrpPut resultant binary into /usr/local/bin40
Running StayRTRpStayRTR has lots of optionsnThe ones we need are:-bind stringBind address (default ":8282")-cache stringURL of the cached JSON data ")pWe have set up our rpki-client to save the data in/var/db/rpki-clientnSo we run the client like this:/usr/local/bin/stayrtr –bind :3323 –cache /var/db/rpki-client/json41
RP Cache DeploymentpNetwork Operator design advice:nnnDeploy at least two Validator CachesGeographically diversePerhaps two different implementationspnnImplement on a Linux container so that the container can bemoved between different server clusters as requiredConfigure validator to listen on both IPv4 and IPv6pnFor software independenceConfigure routers with both IPv4 and IPv6 validator connectionsSecuring the validator: Only permit routers running EBGP tohave access to the validators42
RP Cache Deployment: Open QuestionspConsider two different validator cache implementationsnnnGives software independenceWhat happens if the different cache implementations containdifferent VRPs?Scenario 1:ppnScenario 2:ppnCache 1: route X is validCache 2: route X is invalidCache 1: route X is validCache 2: route X is NotFoundAnswer: depends on router vendor implementation?!43
Configure Router to Use Cache: Cisco IOSpPoint router to the local RPKI cachennnServer listens on port 3323Cache refreshed every 60 minutes (RFC8210 recommendation)Example:router bgp 64512bgp rpki server tcp 10.0.0.3 port 3323 refresh 3600nOnce the router’s RPKI table is populated, router indicatesvalidation state in the BGP table44
Cisco IOS status commandsp show ip bgp rpki serversnpshow ip bgp rpki tablenpDisplays the connection status to the RPKI cachesShows the VRPs (validated ROA payloads)show ip bgpShows the BGP table with status indication next to the prefixshow ip bgp i VnpnShows the status ”valid” prefixes in the BGP table45
Configure Router to Use Cache: JunOS1.Connect to validation cache:routing-options {validation {group ISP {session 10.0.0.3;port 3323;refresh-time 600;hold-time 3600;}}}n(using same parameters as for the Cisco IOS example)46
Configure Router to Use Cache: JunOS2.Configure validation policies:policy-options {policy-statement RPKI-validation {term VALID {from {protocol bgp;validation-database valid;}then {validation-state valid;next policy;}}term INVALID {from {protocol bgp;validation-database invalid;}then {validation-state invalid;next policy;}}(continued).term UNKNOWN {from {protocol bgp;validation-database unknown;}then {validation-state unknown;next policy;}}}}47
Configure Router to Use Cache: JunOS3.Apply policy to eBGP session:protocols {bgp {group EBGP {type external;local-address 10.0.1.1;neighbor 10.1.15.1 {description ”ISP Upstream";import [ RPKI-validation Upstream-in ];export LocalAS-out;peer-as 64511;}}}}nNote that policy options Upstream-in and LocalAS-out are thetypical inbound and outbound filters needed for an eBGP session48
JunOS status commandsp show validation session detailnDisplay the details of the connection to the RPKI cachespshow validation replication databasen Shows the VRPs (validated ROA payloads)pshow route protocol bgpnShows the BGP table with status indication next to the prefixshow route protocol bgp validation-state validnShows the status ”valid” prefixes in the BGP table49
Configure Router to Use Cache: FRroutingpPoint router to the local RPKI cachennnServer listens on port 3323Cache refreshed every 60 minutes (RFC8210 recommendation)Example:rpkirpki polling period 3600rpki cache 10.0.0.3 3323 preference 1rpki cache 10.0.1.2 3323 preference 2exitnTwo caches specified for redundancy50
FRrouting status commandsp show rpki cache-connectionnpshow rpki prefix-tablenpDisplays the connection status to the RPKI cachesShows the VRPs (validated ROA payloads)show ip bgpShows the BGP tableshow ip bgp rpki validnpnnShows the status ”valid” prefixes in the BGP table(There are also options for “invalid” and “notfound”)51
Configure Router to Use Cache: BIRD v2pPoint BIRD to the localRPKI cachennnServer listens on port 3323Cache refreshed every 60minutes (RFC8210recommendation)Two caches specified forredundancyroa4 table r4;roa6 table r6;protocol rpki validator1 {roa4 { table r4; };roa6 { table r6; };remote 10.0.0.3 port 3323;retry 300;}protocol rpki validator2 {roa4 { table r4; };roa6 { table r6; };remote 10.0.1.2 port 3323;retry 300;}52
BIRD v2 status commandspshow protocols validator1npDisplays the connection status to the RPKI cache “validator1”show route table r4nShows the IPv4 VRPs (validated ROA payloads)show route table r6npShows the IPv6 VRPs (validated ROA payloads)show route protocol name nShows the BGP table53
Implementation notespCisco IOS/IOS-XEnInvalid prefixes are dropped by defaultpnPrefixes originated locally into IBGP are automatically marked as ValidpppThe operator does not need to define a policy based on validation stateThere is no check against the cached validation tableAllows operator to originate non-signed address blocks or other entity addressspace inside their own IBGPJunOSnComplete separation between validation table and what happens in BGPpThere has to be a specific policy statement for any action based on validationstate54
Implementation notespCisco IOS/IOS-XE/IOS-XRnEvery VRP change causes a route-refresh with its BGP neighbourspnBig impact for BGP sessions carrying a large or the full BGP tablepnBGP customer doing ROV on Cisco router will cause significant impact on theAccess Router CPUCisco’s recommended workaround:ppnEspecially for BGP peers with weak control planes!Transit providers need to be cautious:pnEven though VRP change only affects valid/invalid/notfound statusTurn on “Soft Reconfiguration”Which has memory implications, and blocks access to the route refresh CLISummary: think carefully about using Cisco routers for Route OriginValidation55
Implementation notespOther router implementationsnnnpMost modern implementations save the incoming BGP table prior to policyapplication (ADJ-RIB-IN)Changes in VRPs are applied to this stored BGP tableSimilar behaviour to Cisco’s soft-reconfigurationNB: It’s important not to rely on Route Refresh to implement VRPchangesnnMore and more frequent changes cause more and more refresh requests to peers,consuming peer CPU resources – potentially a denial of service attack on the peerRecommended bk-sidrops-rov-no-rr/56
Implementation notespWhat happens when router cannot contact any validatorcache?nnnpCisco IOS/IOS-XE – empties the VRP table within 5 minutesJuniper & Nokia – keeps VRPs until their preconfigured expiry(default 60 minutes)Other vendors – behaviour untestedDesign advice:nIt is important to ensure that EBGP speaking routers can alwaysremain connected to a validator cachepMinimum of two independent caches recommended!57
Check Serverlg-01-jnb.za sh ip bgp rpki serversBGP SOVC neighbor is 105.16.112.2/43779 connected to port 43779Flags 64, Refresh time is 300, Serial number is 1463607299InQ has 0 messages, OutQ has 0 messages, formatted msg 493Session IO flags 3, Session flags 4008Neighbor Statistics:Prefixes 25880Connection attempts: 44691Connection failures: 351Errors sent: 35Errors received: 0Connection state is ESTAB, I/O status: 1, unread input bytes: 0Connection is ECN DisabledMininum incoming TTL 0, Outgoing TTL 255Local host: 105.22.32.2, Local port: 27575Foreign host: 105.16.112.2, Foreign port: 43779Connection tableid (VRF): 0Courtesy of SEACOM: http://as37100.net58
Check Serverphilip@DREN-THIMPHU-BR show validation session detailSession 103.197.176.141, State: up, Session index: 2Group: DrukREN, Preference: 100Local IPv4 address: 103.197.176.5, Port: 3323Refresh time: 600sHold time: 1800sRecord Life time: 3600sSerial (Full Update): 0Serial (Incremental Update): 1Session flaps: 1Session uptime: 00:19:11Last PDU received: 00:00:34IPv4 prefix count: 94329IPv6 prefix count: 15992Courtesy of DrukREN, Bhutan59
RPKI Table (IPv4) – May 2022252675 BGP sovc network entries using 40428000 bytes of memory277828 BGP sovc record entries using 8890496 bytes of 68.1.225/332360
RPKI Table (IPv6) – May 202258464 BGP sovc network entries using 10757376 bytes of memory61566 BGP sovc record entries using 1970112 bytes of 8.1.225/3323192.168.1.225/3323192.168.1.225/332361
BGP Table (IPv4)RPKI validation codes: V valid, I invalid, N Not foundNetworkMetric LocPrf PathN* 1.0.4.0/24037100 6939 4637 1221 38803 56203 iN* 1.0.5.0/24037100 6939 4637 1221 38803 56203 i.V* 1.9.0.0/16037100 4788 iN* 1.10.8.0/24037100 10026 18046 17408 58730 iN* 1.10.64.0/24037100 6453 3491 133741 i.V* 1.37.0.0/16037100 4766 4775 iN* 1.38.0.0/23037100 6453 1273 55410 38266 iN* 1.38.0.0/17037100 6453 1273 55410 38266 {38266} i.I*5.8.240.0/23037100 44217 3178 iI*5.8.241.0/24037100 44217 3178 iI*5.8.242.0/23037100 44217 3178 iI*5.8.244.0/23037100 44217 3178 i.Courtesy of SEACOM: http://as37100.net62
BGP Table (IPv6)RPKI validation codes: V valid, I invalid, N Not foundNetworkMetric LocPrf PathN* 2001::/32037100 6939 iN*2001:4:112::/48037100 112 i.V* 2001:240::/32037100 2497 iN* 2001:250::/48037100 6939 23911 45N* 2001:250::/32037100 6939 23911 23910 i.V* 2001:348::/32037100 2497 7679 iN* 2001:350::/32037100 2497 7671 iN* 2001:358::/32037100 2497 4680 i.I*2001:1218:101::/48037100 6453 8151 278 iI*2001:1218:104::/48037100 6453 8151 278 iN*2001:1221::/48037100 2914 8151 28496 iN* 2001:1228::/32037100 174 18592 i.Courtesy of SEACOM: http://as37100.net63
RPKI BGP State: ValidBGP routing table entry for 2001:240::/32, version 109576927Paths: (2 available, best #2, table default)Not advertised to any peerRefresh Epoch 137100 24972C0F:FEB0:11:2::1 (FE80::2A8A:1C00:1560:5BC0) from2C0F:FEB0:11:2::1 (105.16.0.131)Origin IGP, metric 0, localpref 100, valid, external, bestCommunity: 37100:2 37100:22000 37100:22004 37100:22060path 0828B828 RPKI State validrx pathid: 0, tx pathid: 0x0Courtesy of SEACOM: http://as37100.net64
RPKI BGP State: InvalidBGP routing table entry for 2001:1218:101::/48, version 149538323Paths: (2 available, no best path)Not advertised to any peerRefresh Epoch 137100 6453 8151 2782C0F:FEB0:B:3::1 (FE80::86B5:9C00:15F5:7C00) from2C0F:FEB0:B:3::1 (105.16.0.162)Origin IGP, metric 0, localpref 100, valid, externalCommunity: 37100:1 37100:12path 0DA7D4FC RPKI State invalidrx pathid: 0, tx pathid: 0Courtesy of SEACOM: http://as37100.net65
RPKI BGP State: Not FoundBGP routing table entry for 2001:200::/32, version 124240929Paths: (2 available, best #2, table default)Not advertised to any peerRefresh Epoch 137100 2914 25002C0F:FEB0:11:2::1 (FE80::2A8A:1C00:1560:5BC0) from2C0F:FEB0:11:2::1 (105.16.0.131)Origin IGP, metric 0, localpref 100, valid, external, bestCommunity: 37100:1 37100:13path 19D90E68 RPKI State not foundrx pathid: 0, tx pathid: 0x0Courtesy of SEACOM: http://as37100.net66
Using RPKIpNetwork operators can make decisions based on RPKIstate:nnnpInvalid – discard the prefix – many do this now!NotFound – let it through (maybe low local preference)Valid – let it through (high local preference)Some operators even considering making “Not Found” adiscard eventnBut then Internet IPv4 BGP table would shrink to about 250000prefixes and the IPv6 BGP table would shrink to about 55000prefixes!67
Deploying RPKI within an ASpFor fully supported Route Origin Validation across thenetwork:nAll EBGP speaking routers need talk with a validatorppnIBGP speaking routers do not need to talk with a validatorpppSupporting ROV means dropping invalids as they arrive in the networkEBGP speaking routers are part of the operator IBGP meshOnly valid and NotFound prefixes will be distributed from the EBGP speakingroutersThe validation table is not distributed from router to routerRemember:nCisco IOS/IOS-XE drops invalids by default – to allow invalids to bedistributed by IBGP, use the per address-family command:bgp bestpath prefix-validate allow-invalid68
Propagating validation statepRFC8097 describes the propagation of validation statebetween iBGP speakersnnnDefines an opaque extended BGP communityExtended x4300:0:2InvalidThese extended communities can be used in IBGP to allow distribution ofvalidation state along with the prefix if desiredOn Cisco IOS/IOS-XE:neighbor x.x.x.x announce rpki statenFor JunOS, policy needs to be explicitly configured69
Propagating validation statepThere are two important caveats when propagatingvalidation state:nInteroperability – is the defined opaque extended communitysu
BGP Security (BGPsec) pExtension to BGP that provides improved security for BGP routing nPublished as RFC8205 nNot yet deployed pImplemented via a new optional non-transitive BGP attribute (BGPsec_PATH) that contains a digital signature pBGPsec supplements BGP origin validation nAllows routers to generate, propagate, and validate BGP update messages with the BGPsec_PATHattribute set
