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