Routing Security Roadmap

JobSnijdersNTTCommunications

job@ntt.netThispresentationcontainsprojectionsandotherforward-lookingstatementsregardingfutureeventsorourfutureroutingperformance.Allstatementsotherthanpresentandhistoricalfactsandconditionscontainedinthisrelease,includinganystatementsregardingourfutureresultsofoperationsandroutingpositions,businessstrategy,plansandourobjectivesforfutureoperations,areforward-lookingstatements(withinthemeaningofthePrivateSecuritiesLitigationReformActof1995,Section27AoftheSecuritiesActof1933,asamended,andSection21EoftheSecuritiesExchangeActof1934,asamended).Thesestatementsareonlypredictionsandreflectourcurrentbeliefsandexpectationswithrespecttofutureeventsandarebasedonassumptionsandsubjecttoriskanduncertaintiesandsubjecttochangeatanytime.Weoperateinaverycompetitiveandrapidlychangingenvironment.Newrisksemergefromtimetotime.Giventheserisksanduncertainties,youshouldnotplaceunduerelianceontheseforward-lookingstatements.Actualeventsorresultsmaydiffermateriallyfromthosecontainedintheprojectionsorforward-lookingstatements.Someofthefactorsthatcouldcauseactualresultstodiffermateriallyfromtheforward-lookingstatementscontainedhereininclude,withoutlimitation:(i)thecontractionorlackofgrowthofmarketsinwhichwecompeteandinwhichourproductsaresold(ii)unexpectedincreasesinourexpenses,includingmanufacturingexpenses,(iii)ourinabilitytoadjustspendingquicklyenoughtooffsetanyunexpectedrevenueshortfall,(iv)delaysorcancellationsinspendingbyourcustomers,(v)unexpectedaveragesellingpricereductions,(vi)thesignificantfluctuationtowhichourquarterlyrevenueandoperatingresultsaresubjectduetocyclicalityinthewirelesscommunicationsindustryandtransitionstonewprocesstechnologies,(vii)ourinabilitytoanticipatethefuturemarketdemandsandfutureneedsofourcustomers,(viii)ourinabilitytoachievenewdesignwinsorfordesignwinstoresultinshipmentsofourproductsatlevelsandinthetimeframeswecurrentlyexpect,(ix)ourinabilitytoexecuteonstrategicalliances,(x)theimpactofnaturaldisastersonoursourcingoperationsandsupplychain,and(xi)otherfactorsdetailedindocumentswefilefromtimetotimewiththeSecuritiesandExchangeCommission.Forward-lookingstatementsinthisreleasearemadepursuanttothesafeharborprovisionscontainedinthePrivateSecuritiesLitigationReformActof1995.

Why are we doing any of this?

• Creatingfiltersbasedonpublicdata,forcesmaliciousactorstoleaveatrailinIRR,WHOISorotherdatasources:auditability

• Bugshappen!–yourroutermaysuddenlyignorepartsofyourconfiguration,you’llthenrelyonyourEBGPpeer’sfilters

• Everyonemakesmistakes–atypoiseasilymade

Average view on routing security

Perception: it is hopeless, too many holes…

Exhaustive list of issues in the current ecosystem •  IRRdb/databaseinaccuracy(stale,autopiloted,non-validated)•  IXPsnotfiltering•  LackofPathValidation•  Lackofsufficientandgoodenoughsoftware

IRR – what is broken what can be fixed?

•  SomeIRRdbsdonotperformvalidation•  Meaningthatvirtuallyanyonecancreatevirtuallyanyroute/route6objectandsneakthoseintotheprefix-filters

•  ElevenrelevantIRRsnotvalidating:RIPE,NTTCOM,RADB,ALTDB,ARINIRR,BBOI,BELL,LEVEL3,RGNET,TC,CANARIE

•  Twosolutions:•  Lockthedatabasedown(RIPE/RIPE-NONAUTH)•  Filteronthemirrorlevel

RIPE NWI-5 proposal & implementation

• RIPENCC’sIRRpreviouslyallowedanyonetoregisteranynon-RIPE-managedspaceifithadnotyetbeenregistered.*DANGER*

•  The“RPSL”password&maintainerwasusedforthis

Threestepsweretaken:• Cannotregisternon-RIPE-managedspaceanymore• Allnon-RIPEspacemovedtoseparate“RIPE-NONAUTH”database• Route/route6ASNauthorizationruleshavebeenimproved

Moreinfo:https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation

OK – so current status

•  TenrelevantIRRsnotvalidating:NTTCOM,RADB,ALTDB,ARINIRR,BBOI,BELL,LEVEL3,RGNET,TC,CANARIE

• Done:RIPE

ARIN community also recognized this is an issue • ConsultationatNANOGandthroughARIN-Consultmailinglist• https://www.arin.net/vault/resources/routing/2018_roadmap.html• https://teamarin.net/2018/07/12/the-path-forward/

“Improve,orkillit”

OK – so current status

• NinerelevantIRRsnotvalidating:NTTCOM,RADB,ALTDB,BBOI,BELL,LEVEL3,RGNET,TC,CANARIE

• Done:RIPE,ARINIRR

• Howtodealwiththeremainingnine….?• Notallofthesearesoeasilycommunicatedwith,notallarereallyactivelymanaged

The “IRR” system access

•  TheIRRisaccessthroughpredominantlytwo“gateways”•  whois.radb.net (thebgpq3andpevaldefault)•  rr.ntt.net

• Allmirroringisessentiallydonewithonesoftware:IRRdSolution:Let’susethehegemonicduopolyforgood!

Improving security at the ”aggregator”?

RIPEIRR

NTTCOM

RADB

APNIC

…

whois.radb.net

rr.ntt.net

bgpq3

DatasourcesAggregators

Clients

Proposal: Let RPKI “drown out” conflicting IRR • RPKIcanbeusedforBGPOriginValidation–butalsoforotherthings!• ARPKIROAissortofaroute-object

•  Ithasa“prefix”,“origin”and“source”(theroot)• WecanuseRPKIROAsforprovisioningBGPprefix-filters

•  ExtendIRRdsothatwhenIRRinformationisindirectconflictwithaRPKIROA–theconflictinginformationissuppressed(Github)

RPKI filter at the aggregators

RIPEIRR

NTTCOM

RADB

APNIC

…

whois.radb.net

rr.ntt.net

bgpq3

DatasourcesAggregators

Clients

RPKI suppressing conflicting IRR advantages • Industry-widecommonmethodtogetridofstaleproxyrouteobjects–bycreatingaROAyouhideoldgarbageinIRRs

• BycreatingaROA–youwillsignificantlydecreasethechancesofpeoplebeingabletouseIRRtohijackyourresource

OK – so current status

•  IRRsnotvalidating:nolongerrelevant

• Done:RIPE,ARINIRR,NTTCOM,RADB,ALTDB,BBOI,BELL,LEVEL3,RGNET,TC,CANARIE

NTT&DashcarehavestartedafullrewriteofIRRdtomakethispossible:https://github.com/irrdnet/irrd4

”Filtering at IXPs is hard”

• ManyIXPshavecometorealizetheirresponsibilitiestotheInternetecosystemandthecommercialbenefitsofamoresecureproduct.

• http://peering.exposed/•  9outoftop10IXPsarefiltering,tenthwilllaterthisyear.IX.brmakinggoodprogtress

•  IXPfilteringhasbecomemucheasier,therearemultiplefullyfeaturedconfigurationgenerators:

•  https://www.ixpmanager.org/•  http://arouteserver.readthedocs.io/

• BIRD’shegemonyintherouteserversoftwareisbeingchallenged:OpenBGPDisfundedtobeabletocompete

Route servers must begin dropping RPKI Invalids • RouteserversbydefinitionprovidepartialInternettables• NoguaranteeswhatsoeverthatagivenroutewillbeavailableviaRS• Whenarouteserverdropsaprefix,worstcasescenarioisrerouting–notanoutage.

NetworkA

NetworkB

ISP

InternetExchange

Not everyone needs to do RPKI

• Becauseofthecentralizationoftheweb,ifaselectfewcompaniesdeployRPKIOriginValidation–millionsofpeoplebenefit

•  (google,cloudflare,amazon,pch/quad9,facebook,akamai,fastly,libertyglobal,comcast,etc…)

•  Ithinkonly20companiesorsoneedtodoOriginValidationfortheretobebigbenefits…

• https://dyn.com/blog/bgp-dns-hijacks-target-payment-systems/

“RPKI Origin Validation is useless without Path Validation aka BGPSEC” • Thelackofpathvalidationcanberesolvedthroughtwomethods:• Denselypeerwitheachother(Example:Google&Akamaihave126+facilitiesincommonwitheachother)

• AnAS_PATHblockingmechanismslike“peerlock”• Botheffectivelyare“pathvalidationfor1hop”• Perhaps“1hop”alreadyisgoodenoughJ

“There is no healthy software ecosystem”

• RIPENCCValidatorv3isworksandactivelymaintained• NLNetlabsiswritingaRPKICacheValidator(Routinator3000)• AcompanyIcan’tnameissecretlywritingonetoo

• AlmostallseriousroutingvendorshaveRPKIsupport(Cisco,Juniper,BIRD,Nokia,FRR–andmoreareontheway)

•  Solution:moreusersresultsinbettersoftware,startusing!

Timeline

• IXPs–startdoingRPKIOriginValidationonyourrouteserversnow

• ISPs/CDNs• ifyouarepointingdefaultsomewhere,doitnow• Ifyouaretransit-free,waitabit

We aren’t done yet - Future work

• UsetheRPKItopublish“peerlock”rulesaboutwhoareauthorizedupstreamsandwhoaren’t

•  https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification•  https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile

•  ExtendtheRPKItoreplaceIRRAS-SETs(IRR/RPKIfeatureparity)•  https://tools.ietf.org/html/draft-ss-grow-rpki-as-cones

• ARINTALissueneedsaddressing

LACNIC RPKI invalids

Source:https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c

Double check your RPKI ROAs!

Source:https://medium.com/@nusenu/where-are-rpki-unreachable-networks-located-65c7a0bae0f8

Conclusion