BGP Security Where we are, what we're trying to do next Russ White - PowerPoint PPT Presentation

BGP Security Where we are, what we're trying to do next Russ White russ@linkedin.com Rule11.us

The Problem Space

Origin & Path Validation • Who really owns 2001:db8:0:1::/64? • How can hijacking or spoofing AS65000 aDacks be resolved? • What if we had some way for AS65000 to know AS65002 is the correct originator? 2001:db8:0:1::/64 2001:db8:0:1::/64 • AS65003 can simply adverLse 2001:db8:0:1::/64 with the AS Path [65002,65003] AS65003 • To resolve this, path valida9on of AS65002 some sort is needed Non-existent link

Valley Free Routing • AS65002 is a customer of AS65000 and 65003 AS65003 • AS65000 adverLses AS65000 2001:db8:0:1::/64 to AS65002 • AS65002 is not a transit AS, so it should not adverLse 2001:db8:0:1::/64 2001:db8:0:1::/64 2001:db8:0:1::/64 towards AS65003 AS65002 • AS65000 needs some way to signal AS65003 that AS65002 is not a transit, so it can reject this adverLsement

Controlling Information Distribution • AS65000 doesn’t want to AS65000 AS65001 AS65002 adverLse it’s connecLon to AS65003 unless the routes are being adverLsed • Backup routes, etc. • AS65000 only wants its connecLon to AS65004 AS65003 AS65004 AS65005 adverLsed to its peers, and not to their peers • Regional rouLng informaLon, partnering relaLonships, etc.

Operational Requirements • No single point of failure • Don’t replace the edge • Don’t tell operators how to run their networks • Don’t slow down convergence • Be quiet

Notes • No single point of failure • Don’t slow down • No single trust anchor • Should converge in near to BGP Lme • No single copy of a database • DDoS protecLon services and the • No single source of informaLon like are a consideraLon • Don’t replace the edge • Be quiet • Edge routers can’t do encrypLon • Don’t tell anyone anything that • Don’t tell operators how to run can’t already be inferred from their network publicly available informaLon • Provide informaLon on which to • Allow filtering of informaLon to form policy, rather than policy protect relaLonships

Current Solutions

RPKI Analysis Positive Negative • ValidaLon/data is out of band • Does not protect against • One-off aDacks • Very low/no informaLon leakage • Any sort of “man in the middle” • Incremental deployment • Difficult to jusLfy for transit • No edge replacement operators • Leaves BGP alone • Concerns around business control over operators by RIRs

BGPSEC Analysis Positive Negative • 100% posiLve aDribuLon of AS • Performance Path • 15x table size • Precludes packing and other • ValidaLon adverLsed in band opLmizaLons • ValidaLon follows rouLng • Signature processed per AS hop informaLon • Replay aDacks are possible • ValidaLon converges at the speed of the control plane • ADacks against Lme can impact • Defeats specific classes of man enLre rouLng system in the middle aDacks • Protects against one off aDacks

BGPSEC Analysis • Every eBGP speaker uses the same cerLficate == security hole AS65000 • Resolved by every eBGP speaker using a different cerLficate • This exposes peering informaLon for each eBGP AS65003 speaker AS65002 Same CerLficate? AS65004

DAG Overlay Analysis Positive Negative • ValidaLon of AS Path • Uses BGP • Requires modificaLon to BGP • ValidaLon adverLsed in overlay • Doesn’t provide the strongest • Defeats specific classes of man level of path protecLon in the middle aDacks • Providers cannot adverLse • Protects against one off aDacks customers • Uses BGP • Well known tools and analysis

Nothing we have today will Deploy 100% • Some won’t deploy at all • What we need is • Something to make mulLple systems work together • Something to get to “good enough” • Hence—a modest proposal…

A (Modest) Proposal

• RPKI • AuthoritaLve root • Slow’ish convergence RPKI + connecLvity informaLon • Find some way to add connecLvity informaLon to the exisLng RPKI • This would be opLonal informaLon, but helpful in validaLng the AS Path

• RPKI • RIR/Public IRR • AuthoritaLve root • AuthoritaLve maintenance • Slow’ish convergence • Fast’ish convergence ROA RPSL + connecLvity + signature informaLon • IRR maintained by RIR’s and “public enLLes” (such as a foundaLon/trust/ company set up for this purpose) • Need to determine how to sign/what to sign with/etc. • Origin informaLon provided by party inserLng data in the IRR • ConnecLvity and policy informaLon opLonally provided by party inserLng data in the IRR

• RPKI • RIR/Public IRR • Private IRR • AuthoritaLve root • AuthoritaLve maintenance • Provider maintenance • Slow’ish convergence • Fast’ish convergence • Fast’ish convergence ROA RPSL RPSL + connecLvity + signature + signature informaLon • IRR maintained by Ler 1 and other providers • Need to determine how to sign/what to sign with/etc. • Origin informaLon provided by party inserLng data in the IRR, validated by the providers • Assuming this informa9on would mostly be provider’s customers • ConnecLvity and policy informaLon opLonally provided

• RPKI • RIR/Public IRRs • Private IRRs • Table Analysis • AuthoritaLve root • AuthoritaLve maintenance • Provider maintenance • Open source tooling • Slow’ish convergence • Fast’ish convergence • Fast’ish convergence • Locally maintained/processed ROA RPSL RPSL Table Info + connecLvity + signature + signature informaLon • Mines route views and other sources • Stable origin informaLon • Stable AS connecLvity informaLon • Feeds into a local system • Open source tool set

• RPKI • RIR/Public IRRs • Private IRRs • Route Views Analysis • AuthoritaLve root • AuthoritaLve maintenance • Provider maintenance • Open source tooling • Slow’ish convergence • Fast’ish convergence • Fast’ish convergence • Locally maintained/processed ROA RPSL RPSL Table Info + connecLvity + signature + signature informaLon Local IRR Mirror Local Policy Local Valid Route InformaLon

Analysis Positive Negative • Lots of moving parts • ValidaLon of origin and path • But any parLcular AS can use the • ValidaLon level depends on tool set they trust amount of informaLon available • No single point of control • ValidaLon informaLon carried • Receiver focused trust model, outside the rouLng system rather than third party/ authoritaLve focused trust model • No single point of failure or • Current IRR model is “broken” control • Offset by RPKI + private IRRs • Local policy shaped from • Public IRRs sLll need to be cleaned mulLple sources up

Problems to Resolve • RPSL needs some way to restrict propagaLon • CommuniLes or the like to filter what is mirrored where • Signing semanLcs/key sources for RPSL objects • Need to be able to access all sources of informaLon from a single API • The IRR interface is probably the natural candidate • IRR to RPKI API • Route Views informaLon to IRR system/API • Local policy store • Open source/commercial tools • Consistent interface across all routers to express policy

Questions? Russ White russ@linkedin.com Rule11.us