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

AS65003 AS65002 AS65000

Origin & Path Validation

• Who really owns

2001:db8:0:1::/64?

• How can hijacking or spoofing

aDacks be resolved?

• What if we had some way for

AS65000 to know AS65002 is the correct originator?

• AS65003 can simply adverLse

2001:db8:0:1::/64 with the AS Path [65002,65003]

• To resolve this, path valida9on of

some sort is needed

2001:db8:0:1::/64 2001:db8:0:1::/64

Non-existent link

AS65003 AS65002 AS65000

Valley Free Routing

• AS65002 is a customer of

AS65000 and 65003

• AS65000 adverLses

2001:db8:0:1::/64 to AS65002

• AS65002 is not a transit AS, so it

should not adverLse 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 adverLsement

2001:db8:0:1::/64 2001:db8:0:1::/64

Controlling Information Distribution

• AS65000 doesn’t want to

adverLse it’s connecLon to AS65003 unless the routes are being adverLsed

• Backup routes, etc.
• AS65000 only wants its

connecLon to AS65004 adverLsed to its peers, and not to their peers

• Regional rouLng informaLon,

partnering relaLonships, etc.

AS65005 AS65004 AS65000 AS65001 AS65002 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 informaLon
• Don’t replace the edge
• Edge routers can’t do encrypLon
• Don’t tell operators how to run

their network

• Provide informaLon on which to

form policy, rather than policy

• Don’t slow down
• Should converge in near to BGP

Lme

• DDoS protecLon services and the

like are a consideraLon

• Be quiet
• Don’t tell anyone anything that

can’t already be inferred from publicly available informaLon

• Allow filtering of informaLon to

protect relaLonships

Current Solutions

RPKI Analysis

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

control over operators by RIRs

Positive Negative

BGPSEC Analysis

• 100% posiLve aDribuLon of AS

Path

• ValidaLon adverLsed in band
• ValidaLon follows rouLng

informaLon

• ValidaLon converges at the speed
• f the control plane
• Defeats specific classes of man

in the middle aDacks

• Protects against one off aDacks
• Performance
• 15x table size
• Precludes packing and other
• pLmizaLons
• Signature processed per AS hop
• Replay aDacks are possible
• ADacks against Lme can impact

enLre rouLng system

Positive Negative

BGPSEC Analysis

• Every eBGP speaker uses the

same cerLficate == security hole

• Resolved by every eBGP speaker

using a different cerLficate

• This exposes peering

informaLon for each eBGP speaker

AS65003 AS65002 AS65000 AS65004 Same CerLficate?

DAG Overlay Analysis

• ValidaLon of AS Path
• ValidaLon adverLsed in overlay
• Defeats specific classes of man

in the middle aDacks

• Protects against one off aDacks
• Uses BGP
• Well known tools and analysis
• Uses BGP
• Requires modificaLon to BGP
• Doesn’t provide the strongest

level of path protecLon

• Providers cannot adverLse

customers

Positive Negative

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

• RPKI
• AuthoritaLve root
• Slow’ish convergence

+ 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

ROA

• RPKI
• AuthoritaLve root
• Slow’ish convergence

+ connecLvity informaLon

RPSL

• RIR/Public IRR
• AuthoritaLve maintenance
• Fast’ish convergence

+ signature

• 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

ROA

• RPKI
• AuthoritaLve root
• Slow’ish convergence

+ connecLvity informaLon

RPSL

• RIR/Public IRR
• AuthoritaLve maintenance
• Fast’ish convergence

+ signature

• 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

RPSL

• Private IRR
• Provider maintenance
• Fast’ish convergence

+ signature

ROA

• RPKI
• AuthoritaLve root
• Slow’ish convergence

+ connecLvity informaLon

RPSL

• RIR/Public IRRs
• AuthoritaLve maintenance
• Fast’ish convergence

+ signature

• Mines route views and other sources
• Stable origin informaLon
• Stable AS connecLvity informaLon
• 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 InformaLon

ROA

• RPKI
• AuthoritaLve root
• Slow’ish convergence

+ connecLvity informaLon

RPSL

• RIR/Public IRRs
• AuthoritaLve 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

• ValidaLon of origin and path
• ValidaLon level depends on

amount of informaLon available

• ValidaLon informaLon carried
• utside the rouLng system
• No single point of failure or

control

• Local policy shaped from

mulLple sources

• Lots of moving parts
• But any parLcular AS can use the

tool set they trust

• No single point of control
• Receiver focused trust model,

rather than third party/ authoritaLve focused trust model

• Current IRR model is “broken”
• Offset by RPKI + private IRRs
• Public IRRs sLll need to be cleaned

up

Positive Negative

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