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

Victim AS X AS 111 AS 666 168.122/16 Path: 111 168.122/16 Path: X-111 168.122/16 Path: 666

BGP Ad. Data flow prefers shorter route

2

Boston University

RPKI

Resource Public Key Infrastructure (RPKI)

• Origin Authentication

–Protects against hijacks –Slowly gaining traction (6% of prefixes covered)

Verify signature BGP Routers local cache

Autonomous System ROA: AS 111 168.122/16

168.122/16: AS 111 168.122/16: AS 111

RPKI prevents prefix hijacks

Victim AS Y AS X AS 111 AS 666 168.122/16 Path: Y-X-111 168.122/16 Path: 666

BGP Ad. Data flow

ROA: AS 111 168.122/16 RPKI

ROA: AS 111 168.122/16 RPKI

Forged origin circumvents RPKI

Victim AS Y AS X AS 111 168.122/16 Path: Y-X-111 168.122/16 Path: 666-111

BGP Ad. Data flow False link

AS 666

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

AS 111 168.122/16 AS X Prefix: 168.122/16 Secure-Path: X-111 AS Y Prefix: 168.122/16 Secure-Path: Y-X-111

Matches RPKI policy? 168.122/16: AS 111 Path signature OK?

Add signature, then relay

Matches RPKI policy? Path signatures valid?

BGPsec in partial adoption? Meager benefits [Lychev et al., SIGCOMM’13]

Victim AS Y AS X AS 666 AS 111 BGP BGPsec ROA: AS 111 168.122/16 RPKI

168.122/16 Sec Path: X-111

168.122/16 Path: 666-111

BGPsec in partial adoption? Meager benefits [Lychev et al., SIGCOMM’13]

Victim AS Y AS X AS 666 168.122/16 Path: Y-X-111 AS 111 BGP BGPsec ROA: AS 111 168.122/16 RPKI “Breaks” BGPsec 168.122/16 Path: 666-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

Victim AS Y AS X AS 111 AS 666 168.122/16 Path: Y-X-111 168.122/16 Path: 666-111

BGP Ad. Data flow False link

ROA: AS 111 168.122/16 RPKI RPKI path end Edge auth: AS 111 AS X Covers all edges

Inter domain routing security: Mechanism comparison

5 10 15 20 25 30 35 40 45 50

Attacker success rate (%) Protocol

BGP (no auth.) RPKI RPKI + Path-end validation RPKI + BGPsec, BGP still allowed This talk

path-end validation

Path-end validation

• Path-end validation extends RPKI to authenticate

the “last hop”

• Key insight: Securing path-suffixes provides

significant benefits

d v a

Prefix

RPKI Did d approve reaching it via v?

Path-end validation

4 4.5 3.5

Deployment

• Similar to RPKI

Verify signatures BGP Routers RPKI Local cache 168.122/16: AS 111 AS 111  AS X 168.122/16: AS 111 AS 111  AS X

ROA: 168.122/16 -> AS 111

Path End

RPKI Edge auth: AS 111 -> AS X Autonomous System

Deployment

• Use existing Access List interface
• Validated suffix extends automatically with adoption

ip as-path access-list as1 deny _[^X]_111_

Security in partial adoption: Simulation framework

B D H J E I G K L F C A

• Pick victim & attacker
• Victim’s prefix has a ROA+EA
• Pick set of filtering ASes
• Evaluate which ASes send

traffic to the attacker Empirically-derived AS-level network from CAIDA Including inferred peering links [Giotsas et al., SIGCOMM’13]

ROA: 1.2.0.0/16  AS A Path End

RPKI

Edge auth: AS A  AS D

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