Jumpstarting BGP Security Yossi Gilad Joint work with: Avichai - PowerPoint PPT Presentation

Jumpstarting BGP Security Yossi Gilad Joint work with: Avichai Cohen, Amir Herzberg, and Michael Schapira

Prefix hijacking prefers shorter route Victim 168.122/16 168.122/16 Path: X-111 AS X Path: 666 AS 666 168.122/16 AS Path: 111 111 BGP Ad. Data flow Boston University 2

Resource Public Key Infrastructure (RPKI) • Origin Authentication – Protects against hijacks – Slowly gaining traction (6% of prefixes covered) Verify signature local cache RPKI 168.122/16: AS 111 168.122/16: AS 111 Autonomous ROA: AS 111 System 168.122/16 BGP Routers

RPKI prevents prefix hijacks 168.122/16 168.122/16 Victim Path: Y-X-111 Path: 666 AS Y AS 666 AS X ROA: AS 111 RPKI 168.122/16 AS 111 BGP Ad. Data flow

Forged origin circumvents RPKI 168.122/16 168.122/16 Victim Path: 666-111 Path: Y-X-111 AS Y AS 666 AS X ROA: AS 111 RPKI 168.122/16 AS 111 False link BGP Ad. Data flow

Current paradigm: a two step solution • First, RPKI against prefix-hijacking • Then, add BGPsec – Protects against false paths (e.g., next-AS attacks) – Deployment challenge: •Real -time signature and validation •Different message format Prefix: 168.122/16 Prefix: 168.122/16 Add signature, then relay Secure-Path: Y-X-111 Secure-Path: X-111 Matches RPKI policy? Matches RPKI Path signatures valid? policy? AS 111 AS X 168.122/16: AS 111 AS Y 168.122/16 Path signature OK?

BGPsec in partial adoption? Meager benefits [Lychev et al., SIGCOMM’ 13] 168.122/16 Victim Path: 666-111 AS Y AS 666 168.122/16 ROA: AS 111 Sec Path: X-111 AS X RPKI 168.122/16 BGPsec BGP AS 111

BGPsec in partial adoption? Meager benefits [Lychev et al., SIGCOMM’ 13] 168.122/16 168.122/16 Victim Path: 666-111 Path: Y-X-111 AS Y “Breaks” AS 666 BGPsec ROA: AS 111 AS X RPKI 168.122/16 BGPsec BGP AS 111

Our Goals Security : • Protect against ``false links’’ in BGP advertisements • Significant benefits in partial deployment – In contrast to BGPsec Deployment : • Minimal computation overhead – Signatures and verifications: only offline, off-router • No changes to BGP messages • Similar to RPKI

Path-end validation 168.122/16 168.122/16 Victim Path: 666-111 Path: Y-X-111 AS Y AS 666 AS X ROA: AS 111 Edge auth: path RPKI RPKI 168.122/16 AS 111  AS X end AS Covers all 111 False link BGP Ad. Data flow edges

Inter domain routing security: Mechanism comparison 50 BGP (no auth.) 45 Attacker success rate (%) 40 35 RPKI 30 This talk 25 RPKI + Path-end validation 20 15 RPKI + BGPsec, BGP still 10 allowed 5 0 Protocol

Path-end validation • Path-end validation extends RPKI to authenticate the “last hop” • Key insight: Securing path-suffixes provides significant benefits RPKI Prefix d v path-end validation a Did d approve reaching it via v?

Path-end validation 4.5 4 3.5

Deployment • Similar to RPKI Verify signatures Local cache RPKI Path End RPKI ROA: 168.122/16: AS 111 168.122/16: AS 111 AS 111  AS X AS 111  AS X 168.122/16 -> AS 111 Autonomous Edge auth: System AS 111 -> AS X BGP Routers

Deployment ip as-path access-list as1 deny _[^X]_111_ • Use existing Access List interface • Validated suffix extends automatically with adoption

Security in partial adoption: Simulation framework • Pick victim & attacker RPKI A • Victim’s prefix has a ROA+EA B • Pick set of filtering ASes ROA: C • Evaluate which ASes send 1.2.0.0/16  AS A traffic to the attacker D E F G Path End H I Edge auth: J AS A  AS D K L Empirically-derived AS-level network from CAIDA Including inferred peering links [Giotsas et al., SIGCOMM’ 13]

Simulation results

Simulation results

Simulation results

Local deployment & local benefits

Impact of authenticating hops BGP (no authentication) Origin authentication (RPKI) Path-end validation 2-hop validation

More results • Large content providers are better protected • Path-end validation mitigates high profile incidents • Security monotone – BGPsec is not [ Lychev et al., SIGCOMM’ 13]

Conclusion • Path-end validation – Can significantly improve inter-domain routing security while avoiding BGPsec’s deployment hurdles • We advocate – Extending RPKI to support path-end validation – Regulatory/financial efforts on gathering critical mass of adopters

Thank You