BGP Validation Russ White Rule11.us

The Problem Space

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

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

Controlling Information Distribution AS65000 doesn’t want to advertise it’s connection to AS65003 unless the routes are being advertised Backup routes, etc. AS65000 only wants its connection to AS65004 advertised to its peers, and not to their peers Regional routing information, partnering relationships, etc. AS65005 AS65004 AS65000AS65001AS65002 AS65003

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 No single trust anchor No single copy of a database No single source of information Don’t replace the edge Edge routers can’t do encryption Don’t tell operators how to run their network Provide information on which to form policy, rather than policy Don’t slow down Should converge in near to BGP time DDoS protection services and the like are a consideration Be quiet Don’t tell anyone anything that can’t already be inferred from publicly available information Allow filtering of information to protect relationships

RPKI

Origin Authentication AS65002 authorized to originate 2001:db8:0:1::/64 AS65002 creates an RC signed with a private key and any additional parameters AS65002 places this in the RPKI database RIR (Trust Anchor) Route Origin Authorization (ROA) 2001:db8:0:1::/64 Resource Certificate (RC) AS65000 AS65003 AS65002

Origin Authentication AS65000 uses AS65002’s public key to validate the ROA AS65000 can check the original authorization using the trust anchor’s public key RIR (Trust Anchor) Route Origin Authorization (ROA) 2001:db8:0:1::/64 Resource Certificate (RC) AS65000 AS65003 AS65002

Origin Authentication How are these certificates carried from provider to provider? rsync is used to transport these today There are improvements coming in this area RIR (Trust Anchor) Route Origin Authorization (ROA) 2001:db8:0:1::/64 Resource Certificate (RC) AS65000 AS65003 AS65002

Origin Authentication How does the actual edge router check against a local copy of this database? RFC6810: The Resource Public Key Infrastructure (RPKI) to Router Protocol RIR (Trust Anchor) Route Origin Authorization (ROA) 2001:db8:0:1::/64 Resource Certificate (RC) AS65000 AS65003 AS65002

BGPSEC

Operation Certificate added as BGP attribute Signature (hash created using private key) Private key retrieval information Valid lifetime Other information… Certificate is around 256 octets Exchange of certificates attributes is negotiated at initial peering /24 AS65000 AS65001 AS65002 NLRI: 2001:db8:0:1::/64 Attributes: Communities, Certificate, etc. NLRI: 2001:db8:0:1::/64 Attributes: Communities, Certificate, etc.

Operation Receiving Speaker Calculates hash based on retrieved public key for each AS in the AS Path Compares calculated hash against hash carried in the certificate within the update Sending Speaker Adds a new certificate containing the sending AS and receiving AS Calculates a hash across any existing certificates and this new information Inserts the certificate into the attributes /24 AS65000 AS65001 AS65002 Signs across ([65000,65001], /24) Validates signature using public key against ([65000,65001], /24) Signs across ([first hop signature, [65001,65002]) Validates using AS65000 public key for first hop signature, AS65001 public key for second hop signature

Analysis 100% positive attribution of AS Path Validation advertised in band Validation follows routing information Validation converges at the speed of the control plane Defeats specific classes of man in the middle attacks Protects against one off attacks Performance 15x table size Precludes packing and other optimizations Signature processed per AS hop Replay attacks are possible Attacks against time can impact entire routing system General PositiveNegative

Analysis Every eBGP speaker uses the same certificate == security hole Resolved by every eBGP speaker using a different certificate This exposes peering information for each eBGP speaker Information Leakage AS65003 AS65002 AS65000 AS65004 Same Certificate?

Graph (DAG) Based

Operation AS Level semantics Only AS level changes are reflected in the base advertisements More detail may be included Such as policy Which neighboring AS is not transit, etc. Path Validation AS65003 AS65002 AS65000 AS65004 Connected to AS65003 Connected to AS65002 Connected to AS65000 Connected to AS65004 Connected to AS65000 Connected to AS65004 Connected to AS65003 Connected to AS65002

Operation For instance, if an advertisement is received with the AS path [65004,65003] at AS65000 Is AS65004 connected to AS65003? Yes Is there any policy along the path that says I shouldn’t be receiving this route? No Am I connected to AS65000? Yes 80%+ certain this is a good route Leave it to reactive/future systems to resolve the rest Path Validation

Operation Overlay carrying new information Carried in BGP Can be carried multihop as an overlay Can be carried edge to edge Each AS can make a different decision Incremental deployment should add value incrementally Transport AS65005 AS65004 AS65000AS65001AS65002 AS65003

Route Origin Authorization (ROA) Route Origination Resource Certificate AS Connectivity Certificate 1 AS Connectivity Certificate 2 AS Connectivity Certificate 3 BGP AFACC 1Community Other Attributes ACC 2Community Other Attributes Potential Address Family Format

Analysis Validation of AS Path Validation advertised in overlay Defeats specific classes of man in the middle attacks Protects against one off attacks Uses BGP Well known tools and analysis Uses BGP Requires modification to BGP Doesn’t provide the strongest level of path protection Many providers don’t want to advertise their connectivity and policies PositiveNegative

A (Potential) Proposal

RPKI Authoritative root Slow’ish convergence + connectivity information Find some way to add connectivity information to the existing RPKI This would be optional information, but helpful in validating the AS Path

ROA RPKI Authoritative root Slow’ish convergence + connectivity information RPSL RIR/Public IRR Authoritative maintenance Fast’ish convergence + signature IRR maintained by RIR’s and “public entities” (such as a foundation/trust/company set up for this purpose) Need to determine how to sign/what to sign with/etc. Origin information provided by party inserting data in the IRR Connectivity and policy information optionally provided by party inserting data in the IRR

ROA RPKI Authoritative root Slow’ish convergence + connectivity information RPSL RIR/Public IRR Authoritative maintenance Fast’ish convergence + signature IRR maintained by tier 1 and other providers Need to determine how to sign/what to sign with/etc. Origin information provided by party inserting data in the IRR, validated by the providers Assuming this information would mostly be provider’s customers Connectivity and policy information optionally provided RPSL Private IRR Provider maintenance Fast’ish convergence + signature

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

Local Valid Route Information ROA RPKI Authoritative root Slow’ish convergence + connectivity information RPSL RIR/Public IRRs Authoritative maintenance Fast’ish convergence + signature RPSL Private IRRs Provider maintenance Fast’ish convergence + signature Table Info Route Views Analysis Open source tooling Locally maintained/processed Local IRR Mirror Local Policy

Analysis Validation of origin and path Validation level depends on amount of information available Validation information carried outside the routing system No single point of failure or control Local policy shaped from multiple sources Lots of moving parts But any particular AS can use the tool set they trust No single point of control Receiver focused trust model, rather than third party/authoritative focused trust model Current IRR model is “broken” Offset by RPKI + private IRRs Public IRRs still need to be cleaned up PositiveNegative

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

Questions? Russ White Rule11.us