How Small Groups Can Secure
Interdomain Routing
Martin Suchara
in collaboration with
I. Avramopoulos and J. Rexford
Interdomain Routing (BGP) is not Secure

BGP is vulnerable to:
 Deliberate attacks
 Misconfigurations

Yet, users demand:
 Confidentiality
 Integrity
 Availability
2
Securing Interdomain Routing

Users demand:
 Confidentiality
 Integrity
 Availability

Existing crypto solutions

Focus of this work
3
Overview
I.
The routing system and its vulnerabilities
II.
Why should small groups secure BGP
III.
Securing BGP in small groups – effectiveness of
techniques
IV.
Our approach
V.
a)
SBone – secure overlay routing
b)
Shout – hijacking the hijacker
Conclusion
4
Interdomain Routing – Terminology

Autonomous Systems (ASes) = independently
administered networks in a loose federation

Prefix = set of IP addresses

Origin = genuine owner of an address prefix

Route = AS-level path to the origin
Origin of 12.34.*
AS #1
Yale
1
AS #2
AT&T
Data packets
21
AS #3
Princeton
Routing announcements
5
Interdomain Routing – Protocol Based on
Trust

BGP is prefix-based path-vector protocol
 Each AS maintains a set of routes to all prefixes
 One “best” route is used
Originate 12.34.*
21
1
AS1→12.34.*
AS #1
12.34.*
AS2 → AS1 → 12.34.*
AS #2
AS #3
AS #4
6
1
Interdomain Routing – Export & Policies

Customer-provider and peer-peer relationships

Selecting a route: by assumption the most
profitable, shortest route preferred

At most one profitable route exported
National
ISP (#1)
Regional
ISP (#3)
Cust. #6
customerprovider
National
ISP (#2)
Regional
ISP (#4)
peer-peer
Regional
ISP (#5)
Cust. #7
7
12.34.*
Interdomain Routing – Export & Policies

Customer-provider and peer-peer relationships

Selecting a route: by assumption the most
profitable, shortest route preferred

At most one profitable route exported
National
ISP (#1)
Regional
ISP (#3)
Cust. #6
12.34.*
National
ISP (#2)
Regional
ISP (#4)
Use: 6
Remember: 36
Regional
ISP (#5)
Cust. #7
8
Interdomain Routing – One Cannot Learn
Many Routes

Customer-provider and peer-peer relationships

Selecting a route: by assumption the most
profitable, shortest route preferred

At most one profitable route exported
National
ISP (#1)
Regional
ISP (#3)
Cust. #6
12.34.*
National
ISP (#2)
Regional
ISP (#4)
Use: 6
Remember: 36
Regional
ISP (#5)
Cust. #7
9
Vulnerabilities – Example 1

Invalid origin attack
 Nodes 1, 3 and 4 route to the adversary
 The true destination is blackholed
1
2
3
4
6
12.34.*
Attacker
5
Genuine
origin
7
10
12.34.*
Vulnerabilities – Example 2

Adversary spoofs a shorter path
 Node 4 routes through 1 instead of 2
 The traffic may be blackholed or intercepted
No attack
1
2
3
6
4
Thinks route
thru 2 shorter
5
Genuine
origin
7
11
12.34.*
Vulnerabilities – Example 2

Adversary spoofs a shorter path
 Node 4 routes through 1 instead of 2
 The traffic may be blackholed or intercepted
Announce
17
1
2
3
6
4
Thinks route
thru 1 shorter
5
Genuine
origin
7
12
12.34.*
Overview
I.
The routing system and its vulnerabilities
II.
Why should small groups secure BGP
III.
Securing BGP in small groups – effectiveness of
techniques
IV.
Our approach
V.
a)
SBone – secure overlay routing
b)
Shout – hijacking the hijacker
Conclusion
13
State of the Art – S-BGP and soBGP

Mechanism: identify which routes are invalid and
filter them

S-BGP
 Certificates to verify origin AS
 Cryptographic attestations added to routing
announcements at each hop

soBGP
 Build a (partial) AS level topology database
14
Limitations of the Secure Protocols

Previous solutions
 Benefits only for large deployments (~10,000s)
 No incentive for early adopters
 No deployment for over a decade

Our goal: Provide incentives to early adopters!
15
Our Approach

Secure routing within a small group
 10-20 cooperating nodes
 All participants’ routes are secured

Challenges
 Non-participants outnumber participants
 Participants rely on non-participants
 Each AS exports only one route

Focus on raising the bar for the adversary rather
than residual vulnerabilities
16
Overview
I.
The routing system and its vulnerabilities
II.
Why should small groups secure BGP
III.
Securing BGP in small groups – effectiveness of
techniques
IV.
Our approach
V.
a)
Sbone – secure overlay routing
b)
Shout – hijacking the hijacker
Conclusion
17
Experimental Evaluations

Performance of existing techniques
 They work well in large scale deployments
 How do they do in small groups?

Evaluate performance of state-of-the art: soBGP
 Evaluate partial deployment
 If two ASes participate, a valid link connecting
them must be in the registry
18
Experimental Setup – All Experiments

Method – simulation of BGP announcements on the
AS-level Internet topology
 Topology information from RouteViews
 Adversary and origin chosen at random
 Participants implement secure protocol
 1 or 5 adversaries

Performance metric – fraction of the Internet ASes
with valid routes
 Average of 100 runs
19
soBGP – Random Participation,
1 adversary
Percentage of ASes
% of the Internet
with valid routes
Participants have a higher
chance to have a valid route!
Groups of 1 – 30
participants
Participant ASes
All ASes
Number of Participant ASes
20
Percentage of ASes
soBGP – Deployment by 30 Random +
Some Largest ISPs
Better performance
Cooperation of many
large ISPs needed!
Participant ASes
All ASes
Number of Large ISPs
21
Perfect Detection

Simulations: give ability to detect routes that don’t
work
 Is this sufficient to secure routing?
 How useful is it to have perfect detection?

Can be done in practice:
 Data-plane probing verifies validity of route by
using it
22
Percentage of ASes
Perfect Detection at 30 Random + Some
Largest ISPs
Perfect detection helps but
not sufficient by itself!
Participant ASes
All ASes
Number of Large ISPs
23
Lessons Learned
Observation
Justification
Participation of large ISPs
is important
They learn many routes
some of which are valid
Perfect detection of bad
routes is desirable
Better (but not ideal)
performance
The non-participants are
worse off than the
participants
The participants reject
implicated routes while nonparticipants accept all
Need to increase path
diversity
Perfect detection not enough
24
Overview
I.
The routing system and its vulnerabilities
II.
Why should small groups secure BGP
III.
Securing BGP in small groups – effectiveness of
techniques
IV.
Our approach
V.
a)
Sbone – secure overlay routing
b)
Shout – hijacking the hijacker
Conclusion
25
Our Approach – Key Ideas

Circumvent the adversary with
secure overlay routing

Hijack the hijacker: all
participants announce the
protected prefix

Hire a few large ISPs to help

Detect invalid routes accurately
with data plane detectors
26
Our Approach – Key Ideas

Circumvent the adversary with
secure overlay routing

Hijack the hijacker: all
participants announce the
protected prefix

Hire a few large ISPs to help

Detect invalid routes accurately
with data plane detectors
27
Our Approach – Key Ideas

Circumvent the adversary with
secure overlay routing

Hijack the hijacker: all
participants announce the
protected prefix

Hire a few large ISPs to help

Detect invalid routes accurately
with data plane detectors
28
Our Approach – Key Ideas

Circumvent the adversary with
secure overlay routing

Hijack the hijacker: all
participants announce the
protected prefix

Hire a few large ISPs to help

Detect invalid routes accurately
with data plane detectors
29
Overview
I.
The routing system and its vulnerabilities
II.
Why should small groups secure BGP
III.
Securing BGP in small groups – effectiveness of
techniques
IV.
Our approach
V.
a)
SBone – secure overlay routing
b)
Shout – hijacking the hijacker
Conclusion
30
Secure Overlay Routing (SBone)

Protects intra-group traffic

Overlay of participants’Use
networks
peer
route
Bad paths detected by probing

Use provider
route
Use longer
route
1
2
Participant
5
Nonparticipant
4
3
Detected as
6
12.34.* ; 12.34.1.1
bad
7
31
12.34.* ; 12.34.1.1
Secure Overlay Routing (SBone)

Traffic may go thru an intermediate node
Uses path thru
intermediate node 3
Forwards
traffic for 1
?
1
2
?
?
5
?
12.8.1.1
4
3
12.34.1.1
12.34.* ; 12.8.1.1
6
7
32
12.34.* ; 12.34.1.1
Percentage of Participating ASes
SBone – 30 Random + Help of Some
Large ISPs
Good performance
even for small groups!
Group Size (ASes)
5 large ISPs
3 large ISPs
1 large ISP
0 large ISPs
33
SBone – Multiple Adversaries
Percentage of Participating ASes
Solution: enlist more large ISPs!
With 5 adversaries, the
performance degrades
5 large ISPs
3 large ISPs
1 large ISP
0 large ISPs
Group Size (ASes)
34
SBone - Summary
Observation
Justification
SBone offers good
availability even for very
small groups
It better exposes path
diversity
Non-participants are not
secure yet
They lack the ability to
tunnel around problems
35
Overview
I.
The routing system and its vulnerabilities
II.
Why should small groups secure BGP
III.
Securing BGP in small groups – effectiveness of
techniques
IV.
Our approach
V.
a)
SBone – secure overlay routing
b)
Shout – hijacking the hijacker
Conclusion
36
Hijacking the Hijacker – Shout

Secure traffic from non-participants

Prefers
Use
shortest
short path
customer’s
All participants
announce
the protected prefix
path
1
4
leading
12.34.* to adversary
Once the traffic enters the overlay, it is securely
forwarded to the true prefix owner

1
2
12.34.*
3
6
12.34.*
4
5
12.34.*
Node 4 shouts
7
37
12.34.*
Percentage of ASes
Shout + SBone – 1 Adversary
With as few as 10 participants
+ 3 large ISPs, 95% of all
ASes can reach the victim!
5 large ISPs
3 large ISPs
1 large ISP
0 large ISPs
Group Size (ASes)
38
Percentage of ASes
Shout + SBone – 5 Adversaries
More adversaries 
larger groups required!
5 large ISPs
3 large ISPs
1 large ISP
0 large ISPs
Group Size (ASes)
39
Performance and Scalability of Shout

Shout can be used reactively
 Only shout if an attack is detected

Changes in routing table sizes negligible
 Alternate routes must be saved in routing tables
 The average table size increased by less than 5%

After shouting path lengths increase modestly
 Paths less than 1.35 times longer
 Detailed results next
40
Shout + SBone – Increase in Path Length
Length Ratio
With as few as 3 large ISPs
the penalty is negligible!
0 large ISPs
1 large ISP
3 large ISPs
5 large ISPs
Group Size (ASes)
41
Shout - Summary
Observation
Justification
Can secure communication It suffices if non-participant
from non-participants
reaches any participant
Routing table sizes do not
increase
Increases < 5%
Shout does not inflate path
lengths significantly
Path lengths increase by
<15% with 3 large ISPs
42
Overview
I.
The routing system and its vulnerabilities
II.
Why should small groups secure BGP
III.
Securing BGP in small groups – effectiveness of
techniques
IV.
Our approach
V.
a)
SBone – secure overlay routing
b)
Shout – hijacking the hijacker
Conclusion
43
Conclusion

BGP should be secured by small groups

To be effective, the group members should
(i) Detect and filter compromised routes accurately
(ii) Cooperate to expose path diversity
(iii) Coax non-participants to pick valid routes
(iv) Enlist a few large ISPs
44
Conclusion

SBone and Shout are novel mechanisms that
achieve these goals

The proposed solution
(i) Secures address space of a small group of
participants
(ii) Allows both participants and non-participants
pick valid routes
(iii) Provides incentives to the adopters
45
Future Work

Deployment in larger groups where participants
don’t trust each other
 Secure routing protocol on the overlay?

Analytic models of the deployment
 Predict which additional ASes to enlist to boost
performance?
 Effects of the structure of the graph on the
outcomes?
46
Thank you for your attention!
47
Discussion
1. Effects of subprefix hijacking
2. What if participants not willing to choose less
profitable routes?
3. What if N large ISPs are used instead of N largest
ones?
4. Average results and error bars
48
1. Subprefix Hijacking

Threat: adversary deaggregates the victim’s prefix,
all traffic is directed to the adversary

Key security mechanisms

Deaggregate the prefix and use shout to
announce it

Tunnel endpoints already secure if announced
with /24 prefixes

Only deaggregate when attack detected

Attack detected if at least one participant sees an
unauthorized subprefix
Percentage of ASes
1. Subprefix Hijacking – Avoiding
Detection
If the adversary conceals the
attack, <5% ASes are affected!
5 large ISPs
3 large ISPs
1 large ISP
Group Size (ASes)
50
1. Subprefix Hijacking - Summary
Observation
Justification
Can secure against
subprefix hijacking
Deaggregation in addition to
shout
Low overhead
Reactive scheme used only
if attack detected
Detection is accurate
Large ISPs have good
connectivity and learn the
offending sub-prefix easily
51
Percentage of Participating ASes
2. SBone – Preserve Business
Relationships?
Participants can influence
route selection
Participants do not have
visibility into BGP; just route
through intermediate nodes
underlay rerouting
no underlay rerouting
Group Size (ASes)
52
3. Effect of Choosing the Largest ISPs

The largest ISPs are similar in terms of connectivity
and size

Which one of these we enlist among the participants
does not matter much
SBone vs. Perfect Detection Alone
Percentage of ASes
Perfect detection alone
SBone
With 5 adversaries and 10
participants the SBone is
better and variance lower!
Stdev: 8%
Stdev: 15%
0 large
ISPs
1 large
ISP
3 large
ISPs
5 large
ISPs
54