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

The Internet

AS 1 AS 666

BGP is insecure!

1.2.0.0/16 is Mine 1.2.0.0/16 is Mine

• Prefix hijack

BGP is insecure! Prefix hijacks

Victim AS 3 AS 2 AS 1 1.2/16 AS 666 1.2/16 Path: 1,2 1.2/16 Path: 1 1.2/16 Path: 1,2,3 1.2/16 Path: 666

BGP Ad. Data flow

Resource PKI (RPKI)

• Origin Authentication
• Protects against prefix/subprefix hijacks
• Slowly gaining traction (protects 6% of prefixes)

Verify signature BGP Routers repository RPKI cache 1.2/16 à AS 1 1.2/16: AS 1 1.2/16: AS 1

The Internet

AS 1 AS 666

BGP is insecure!

1.2.0.0/16 is Mine 1.2.0.0/16 is Mine

• Prefix/Subprefix Hijack

RPKI prevents prefix hijacks

Victim AS 3 AS 2 AS 1 1.2/16 AS 666 1.2/16 Path: 1,2,3 1.2/16 Path: 666

1.2/16 à AS 1 BGP Ad. Data flow

Next-AS attack circumvents RPKI

Victim AS 3 AS 2 AS 1 1.2/16 AS 666 1.2/16 Path: 1,2,3 1.2/16 Path: 1,666

1.2/16 à AS 1 BGP Ad. Data flow False `link’

The Internet

AS 1 AS 666

BGP is insecure!

AS1 is my neighbor

• Next-AS Attack

1.2.0.0/16 is Mine

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 1 1.2/16 AS 2 Prefix: 1.2/16 Secure-Path: 1,2 AS 3 Prefix: 1.2/16 Secure-Path: 1,2,3 Matches RPKI policy? 1.2/16: AS 1 Path signature OK? Add signature, then relay Matches RPKI policy? Path signatures valid?

1.2/16 Path: 1,2

BGPsec in partial adoption?

• AS 666 launches a next-AS attack against AS 1
• Not prevented by BGPsec

“Breaks” BGPsec

Meager benefits [Lychev et al., SIGCOMM’13]

AS 2 AS 1 1.2/16 AS 3 AS 666 Legacy Adopter 1.2/16 Path: 1,666

BGPsec: deployment challenges

• Changes to BGP routers:
• Online crypto requires new hardware

[BGPsec design choices, IETF]

• Different message format
• legacy messages coexist with new format
• BGPsec is not “a minor extension” of BGP

BGPSEC Design Choices and Summary of Supporting Discussions draft-sriram-bgpsec-design-choices-08

Goals

• Easy deployment, minimal overhead
• Signatures and verifications: only offline, off-router
• Significant security benefits in partial deployment
• No changes to routing protocol

Path-end validation

Victim AS 3 AS 2 AS 1 1.2/16 AS 666 1.2/16 Path: 1,2,3 1.2/16 Path: 1,666

1.2/16 à AS 1 AS 1 à AS 2 BGP Ad. Data flow Fake `link’

Path-end validation

• Key insight: “last hop” is critical
• Extend RPKI to authenticate the “last hop”

4 4.5 3.5

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?

4 4.5 3.5

Intuition

• AS 666 wants to attract AS 3’s traffic to IP prefix

1.2.3.0/24, but…

• It can’t announce that it owns the prefix or is

AS 1’s neighbor

• It has to launch 2-hop attack: (prefix: 1,2,666)

AS 2 AS 1 1.2/16 AS 3 AS 666

AS 1 connected to AS 2? AS 1 connected to AS 3?

4 4.5 3.5

Deployment

Verify signature BGP Routers repository RPKI cache 1.2/16: AS 1 AS 1 à AS 2 1.2/16: AS 1 AS 1 à AS 2 1.2/16 -> AS 1 AS 1 -> AS 2

Deployment: today!

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

ip as-path access-list as1 deny _[^2]_1_

Evaluating impact

• How significant is path-end validation?
• Empirically-derived AS-level network from CAIDA
• Including inferred peering links

[Giotsas et al., SIGCOMM’13]

• Evaluate fraction of ASes an attacker can attract
• For different adoption scenarios
• For different types of attack
• Using the simulation framework in [Gill et al., CCR’12]

Simulation results

Simulation results

Simulation results

Impact of authenticating hops

BGP (no authentication) Origin authentication (RPKI) Path-end validation

Local deployment

Additional results

• Local deployment protects local traffic
• Large content providers are better protected
• Path-end validation mitigates high profile incidents
• Security monotone

Conclusion

• Path-end validation
• Is a modest extension to RPKI
• Can significantly impact BGP security while avoiding

BGPsec’s deployment hurdles

• We advocate
• Incorporating path-end validation into the RPKI
• Regulatory/financial efforts on gathering critical mass of

adopters

Thank You