nethide: secure and practical network topology obfuscation · nethide: secure and practical network...
TRANSCRIPT
NetHide: Secure and Practical Network Topology Obfuscation
Roland Meier(1), Petar Tsankov(1), Vincent Lenders(2), Laurent Vanbever(1), Martin Vechev(1)
nethide.ethz.ch
USENIX Security 2018
(2)(1)
2
Public serversBotnet
Link-flooding attacks (LFAs) target the infrastructure
3
Public serversBotnet
Low-rate, legitimate flowsspread over many endpoints
4
Link-flooding attacks (LFAs) target the infrastructure
5
Public serversBotnet
Low-rate, legitimate flowsspread over many endpoints
Link-flooding attacks (LFAs) require knowing the topology
6
Public serversBotnet
?
Public serversBotnet
7
Public serversBotnet
8
$ traceroute X
1
X
Public serversBotnet
9
$ traceroute X
1
X
UDP
dst = X
TTL = 1
Public serversBotnet
10
$ traceroute X
1 —A— 1.755 ms
A
ICMP
TTL Exceeded
src = A
X
UDP
dst = X
TTL = 1
Public serversBotnet
11
$ traceroute X
1 —A— 1.755 ms
2
A X
UDP
dst = X
TTL = 2
Public serversBotnet
12
$ traceroute X
1 —A— 1.755 ms
2
A X
UDP
dst = X
TTL = 2
UDP
dst = X
TTL = 1
Public serversBotnet
13
$ traceroute X
1 —A— 1.755 ms
2 —B— 1.062 ms
A
ICMP
TTL Exceeded
src = B
X
UDP
dst = X
TTL = 2
UDP
dst = X
TTL = 1
B
Public serversBotnet
14
$ traceroute X
1 —A— 1.755 ms
2 —B— 1.062 ms
3 —C— 0.880 ms
A
B
C
ICMP
TTL Exceeded
src = C
X
UDP
dst = X
TTL = 3
Public serversBotnet
15
$ traceroute X
1 —A— 1.755 ms
2 —B— 1.062 ms
3 —C— 0.880 ms
4 —D— 0.929 ms
A
B
C
DICMP
TTL Exceeded
src = D
X
UDP
dst = X
TTL = 4
Public serversBotnet
16
$ traceroute X
1 —A— 1.755 ms
2 —B— 1.062 ms
3 —C— 0.880 ms
4 —D— 0.929 ms
5 —E— 0.827 ms
A
B
C
DE
ICMP
TTL Exceeded
src = E
X
UDP
dst = X
TTL = 5
Public serversBotnet
17
$ traceroute X
1 —A— 1.755 ms
2 —B— 1.062 ms
3 —C— 0.880 ms
4 —D— 0.929 ms
5 —E— 0.827 ms
6 —X— 0.819 msA
B
C
DE
ICMP
TTL Exceeded
src = X
X
UDP
dst = X
TTL = 6
Learning large topologiesby combining many path measurements
18
Measuring ISP Topologies with Rocketfuel
Neil Spring Ratul Mahajan David Wetherall
{nspring,ratul,djw}@cs.washington.eduComputer Science and Engineering
University of WashingtonSeattle, WA 98195-2350
ABSTRACTTo date, realistic ISP topologies have not been accessible to the re-search community, leaving work that depends on topology on anuncertain footing. In this paper, we present new Internet mappingtechniques that have enabled us to directly measure router-level ISPtopologies. Our techniques reduce the number of required tracescompared to a brute-force, all-to-all approach by three orders ofmagnitude without a significant loss in accuracy. They include theuse of BGP routing tables to focus the measurements, exploitingproperties of IP routing to eliminate redundant measurements, bet-ter alias resolution, and the use of DNS to divide each map intoPOPs and backbone. We collect maps from ten diverse ISPs usingour techniques, and find that our maps are substantially more com-plete than those of earlier Internet mapping efforts. We also reporton properties of these maps, including the size of POPs, distribu-tion of router outdegree, and the inter-domain peering structure. Aspart of this work, we release our maps to the community.
Categories and Subject DescriptorsC.2.1 [Communication Networks]: Architecture and Design—topology
General TermsMeasurement
1. INTRODUCTIONRealistic Internet topologies are of considerable importance to
network researchers. Topology influences the dynamics of routingprotocols [2, 10], the scalability of multicast [17], the efficacy ofproposals for denial-of-service tracing and response [16, 11, 21,22], and other aspects of protocol performance [18].Sadly, real topologies are not publicly available because ISPs
generally regard their router-level topologies as confidential. SomeISPs publish simplified topologies on theWeb, but these lack router-level connectivity and POP structure and may be optimistic or outof date. There is enough uncertainty in the properties of real ISPtopologies (such as whether router outdegree distribution follows apower law as suggested in [7]) that it is unclear whether synthetic
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SIGCOMM’02, August 19-23, 2002, Pittsburgh, Pennsylvania, USA.Copyright 2002 ACM 1-58113-570-X/02/0008 ...$5.00.
topologies generated by tools such as GT-ITM [26] or Brite [12]are representative [25].The main contribution of this paper is to present new measure-
ment techniques to infer high quality ISP maps while using as fewmeasurements as possible. Our insight is that routing informationcan be exploited to select the measurements that are most valuable.One technique, directed probing, uses BGP routing information tochoose only those traceroutes that are likely to transit the ISP beingmapped. A second technique, path reductions, suppresses tracer-outes that are likely to follow redundant paths through the ISP net-work. These two techniques reduce the number of traces requiredto map an ISP by three orders of magnitude compared to a brute-force, all-to-all approach, and we show that the savings do not comeat a high cost in terms of accuracy. We also describe a new solutionto the alias resolution problem of clustering the interface IP ad-dresses listed in a traceroute into their corresponding routers. Ournew, pair-wise alias resolution procedure finds three times as manyaliases as prior techniques. Additionally, we use DNS informationto break the ISP maps into backbone and POP components, com-plete with their geographical location.We used our techniques to map ten diverse ISPs – Abovenet,
AT&T, Ebone, Exodus, Level3, Sprint, Telstra, Tiscali (Europe),Verio, and VSNL (India) – by using over 750 publicly availabletraceroute sources as measurement vantage points. These maps aresummarized in the paper.Three ISPs, out of the ten we measured, helped to validate our
maps. We also estimate the completeness of our maps by scan-ning ISP IP address ranges for routers that we might have missed,and by comparing the peering links we find with those present inBGP routing tables. Our maps reveal more complete ISP topolo-gies compared to earlier efforts; we find roughly seven times morerouters and links in our area of focus than Skitter [6].As a second contribution, we examine several properties of the
maps that are both of interest to researchers and likely to be usefulfor generating synthetic Internet maps. We report new results forthe distribution of of POP sizes and the number of times that anISP connects with other networks. Both distributions have signifi-cant tails. We also characterize the distribution of router outdegree,repeating some of the analysis in [7] with richer data.Finally, as one goal of our work and part of our ongoing valida-
tion effort, we are publicly releasing the ISP network maps inferredfrom our measurements. We are also making the entire raw mea-surement data available to researchers; all our maps are constructedwith end-to-end measurements and without the benefit of confiden-tial information. The maps and data are available at [20].The rest of this paper is organized as follows. In Sections 2
and 3, we describe our approach and the mapping techniques re-spectively. The implementation of our mapping engine, Rocket-
133
So the solution is to hide the topology?
yes, but…
20
traceroute is an essential debugging tool
So the solution is to hide the topology?
parts of
So the solution is to hide the topology?
which parts?
how?
parts of
NetHide: Secure and Practical Network Topology Obfuscation
23
NetHide deploys the virtual topology using programmable networks
NetHide works for realistic topologies and maintains the utility of debugging tools
NetHide computes a secure virtual topology that is similar to the physical topology
Reactive and proactive strategies
to mitigate link-flooding attacks
24
Reactive
Proactive
Reactive and proactive strategies
to mitigate link-flooding attacks
25
Reactive act upon detecting a LFA
Proactive
[CoDef, Liaskos, SPIFFY]
▸ cannot prevent LFAs▸ impact on production traffic
Reactive and proactive strategies
to mitigate link-flooding attacks
26
Reactive act upon detecting a LFA
Proactive Aim at preventing LFAs
[CoDef, Liaskos, SPIFFY]
[HoneyNet, Linkbait, Trassare]
▸ cannot prevent LFAs▸ impact on production traffic
▸ make debugging tools unusable
Reactive and proactive strategies
to mitigate link-flooding attacks
27
Reactive act upon detecting a LFA
Proactive Aim at preventing LFAs
[CoDef, Liaskos, SPIFFY]
[HoneyNet, Linkbait, Trassare]
[NetHide]
▸ cannot prevent LFAs▸ impact on production traffic
▸ make debugging tools unusable
NetHide: Secure and Practical Network Topology Obfuscation
28
NetHide deploys the virtual topology using programmable networks
NetHide works for realistic topologies and maintains the utility of debugging tools
NetHide computes a secure virtual topology that is similar to the physical topology
Topology obfuscationas an optimization problem
29
Given the physical topology P,
compute a virtual topology V, such that
V is robust against link-flooding attacks
V has maximal practicality
Given the physical topology P,
compute a virtual topology V, such that
V is robust against link-flooding attacks
V has maximal practicality
Topology obfuscationas an optimization problem
30
Attacker can run flows betweenpairs of routers
31
controls a set of hostsi.e. a botnet
has a budget of flows to runflows between nodes (routers)
has no prior knowledge about topologylearns topology e.g. through traceroute
Attacker
A topology is robust against LFAs, if the flow density of each link does not exceed its capacity
32
Links in V Capacity of the link (max # of flows)
Flow density of the link (# of flows using it)
∀l ∈ L′� : fd(l) ≤ c(l)
A topology is robust against LFAs, if the flow density of each link does not exceed its capacity
33
Links in V Capacity of the link (max # of flows)
Flow density of the link (# of flows using it)
∀l ∈ L′� : fd(l) ≤ c(l)
A topology is robust against LFAs, if the flow density of each link does not exceed its capacity
34
Links in V Capacity of the link (max # of flows)
Flow density of the link (# of flows using it)
∀l ∈ L′� : fd(l) ≤ c(l)
Two basic strategies for attacking the virtual topology despite obfuscation
35
Invert obfuscationand attack based on physical topology
“guess” a promising attackbased on the virtual topology
▸ Infeasible (more later)
▸ Incurs high overhead for attacker (see paper)
Given the physical topology P,
compute a virtual topology V, such that
V is robust against link-flooding attacks
V has maximal practicality
Topology obfuscationas an optimization problem
36
Accuracy and utility measure the closeness of P and V
37
Virtual paths are similar to physical paths
Failures in P are reflected in V
Accuracy and utility measure the closeness of P and V
38
Virtual paths are similar to physical paths
Accuracy
Failures in P are reflected in V
A B C D
A B X D X Y Z
Accuracy and utility measure the closeness of P and V
39
Virtual paths are similar to physical paths
Utility
Accuracy
Failures in P are reflected in V
A B C D
A B X D X Y Z
A B C DX
A C B DX X Y ZX X
Given the physical topology P,
compute a virtual topology V, such that
V is robust against link-flooding attacks
V has maximal practicality
Topology obfuscationas an optimization problem
40
NetHide optimizes over a random sample of solutions
to improve performance and security
41
𝒪(NN)
topology size(# of routers)
all possible solutions
𝒪(N)random sample
better performanceharder to invert obfuscationstill high accuracy and utility
NetHide: Secure and Practical Network Topology Obfuscation
42
NetHide deploys the virtual topology using programmable networks
NetHide works for realistic topologies and maintains the utility of debugging tools
NetHide computes a secure virtual topology that is similar to the physical topology
Deploy the virtual topology V, such that
debugging tools still work
network performance is not impacted
Utility-preservingtopology deployment
43
it scales to large networks
Deploy the virtual topology V, such that
debugging tools still work
network performance is not impacted
Utility-preservingtopology deployment
44
it scales to large networks
Maintaining the utility of debugging toolsrequires sending packets through the actual network
45
Answer from a central controller
Answer at the edge
Answer in a virtual clone of the network
Answer from the correct device that appears on the path
Deploy the virtual topology V, such that
debugging tools still work
network performance is not impacted
Utility-preservingtopology deployment
46
it scales to large networks
Programmable network devices allowmodifying tracing packets at line rate
47
Read & modify packet headerse.g. the TTL value
Basic operationse.g. hash functions and checksums
Add or remove custom headersto store information
Programmable network devicesare configured through match+action tables
48
X
Y
If I receive a packet to X with TTL = i, I should send it to Y with TTL = j
Deploy the virtual topology V, such that
debugging tools still work
network performance is not impacted
Utility-preservingtopology deployment
49
it scales to large networks
Encoding state in packetsinstead of storing it in devices
50
src IP dst IP TTL
src port dst port
payload
IP
UDP
src IP dst IP TTL
src port dst port
payload
IP
Y src IP TTL
TTL exceeded
IP
ICMP
UDP
D Y 1
src port 9999
payload
IP
UDP
src IP dst IP TTL
src port dst port
signature
meta
UDP
D Y 1
src port 9999
payload
IP
UDP
src IP dst IP TTL
src port dst port
signature
meta
Y D TTL
TTL exceeded
IP
ICMP
UDP
D Y
NetHide: Secure and Practical Network Topology Obfuscation
51
NetHide deploys the virtual topology using programmable networks
NetHide works for realistic topologies and maintains the utility of debugging tools
NetHide computes a secure virtual topology that is similar to the physical topology
We evaluated various aspects of NetHide based on 3 real topologies
52
Abilene
Switch
US Carrier
Accuracy and utility
Performance
Timing
Partial deployment
Security
We evaluated various aspects of NetHide based on 3 real topologies
53
Abilene
Switch
US Carrier
Accuracy and utility
Performance
Timing
Partial deployment
Security
54
0
0
100%
100%
Accuracy
Flow density reduction
0
0
100%
100%
Utility
Flow density reduction
Ratio between the flow density in the physical and the virtual topology
0.0 0.2 0.4 0.6 0.8 1.0Flow density reduction factor
0.0
0.2
0.4
0.6
0.8
1.0Av
erag
e ac
cura
cy
0.0 0.2 0.4 0.6 0.8 1.0Flow density reduction factor
0.0
0.2
0.4
0.6
0.8
1.0
Aver
age
utilit
y
0.0 0.2 0.4 0.6 0.8 1.0Flow density reduction factor
0.0
0.2
0.4
0.6
0.8
1.0
% o
f pat
hs w
ith a
cc=1
00%
High protectionwith small impact on accuracy and utility
55
0
0
0.0 0.2 0.4 0.6 0.8 1.0Flow density reduction factor
0.0
0.2
0.4
0.6
0.8
1.0
Aver
age
accu
racy
0.0 0.2 0.4 0.6 0.8 1.0Flow density reduction factor
0.0
0.2
0.4
0.6
0.8
1.0
Aver
age
utilit
y0.0 0.2 0.4 0.6 0.8 1.0Flow density reduction factor
0.0
0.2
0.4
0.6
0.8
1.0
% o
f pat
hs w
ith a
cc=1
00%
100%80%
94%100%
Accuracy
Flow density reduction
0
0
100%80%
100%
Utility
Flow density reduction
bette
r
bette
r
68%
83%
25%
NetHide
Random
82% of paths not changed at all
NetHide: Secure and Practical Network Topology Obfuscation
NetHide deploys the virtual topology using programmable networks
NetHide works for realistic topologies and maintains the utility of debugging tools
NetHide computes a secure virtual topology that is similar to the physical topology
nethide.ethz.ch
NetHide: Secure and Practical Network Topology Obfuscation
Roland Meier�, Petar Tsankov
�, Vincent Lenders
⇧, Laurent Vanbever
�, Martin Vechev
�
�ETH Zürich,
⇧armasuisse
nethide.ethz.ch
NetHide: Secure and Practical Network Topology Obfuscation
Roland Meier�, Petar Tsankov
�, Vincent Lenders
⇧, Laurent Vanbever
�, Martin Vechev
�
�ETH Zürich,
⇧armasuisse
nethide.ethz.ch
Link-Flooding Attacks: DDoS against network core
Botnet Public servers ⇤ Low-rate, legitimate flows
spread over many endpoints
⇤ Flows concentrate at target
link and lead to congestion
Require knowledge about thetopology & forwarding behavior
NetHide: Proactive LFA defense
NetHide obfuscates a network topology such
that an attacker does not see attackable links.
Challenge: Trade-off between
⇤ Security: Hide enough such that an
attacker can not perform the attack
⇤ Practicality: Do not hide too much
for legitimate use of diagnostic tools
NetHide hides the vulnerable physical topology and shows a secure virtual topology
Input Topology obfuscation
Physical topology
A
B
E
FC D Accuracy
Accuracy
compare ( , )
compare ( , )
Utility for failure of link (D,E)________
compare ( , )
compare ( , )
Utility for failure of link (D,E)________
Topology deployment
using programmable network devices
Virtual topology
A
B
E
FC D
dst TTL actions
E 2 TTL=3, dst=D
Random sample ofcandidate solutions
Select topology with maximal accuracy and utility (V2)
bottlenecklink (C,D)
virtual link= 2 common
= 2 common
observe failure (A,E)
observe no failure P
O
= 3 common
= 3 common
observe failure (D,E)
observe no failure P
P
… … …
dst TTL actions
A 3 TTL=4… … …
dst TTL actions
F 3 TTL=4… … …
dst TTL actions
B 3 TTL=4… … …
c(C,D) < fd(C,D)
§ Physical topology
§ Routing behavior
§ Set of flows
§ Capacity of each link
Input:
V1
V2
Deriving a secure and practical topology
Given a physical topology P , NetHide computes
a virtual topology V with the following properties:
⇤ V is secure (no LFA possible);
⇤ Path that a packet takes in V is similar to P ;
⇤ Link failures in P are accurately observed in V .
Network users only see the virtual topology
NetHide uses programmable network devices to rewrite
probing packets (e.g. from traceroute) such that:
⇤ The observed paths match the virtual topology;
⇤ Link failures can be detected;
⇤ There is no impact on the network performance.
NetHide works in practice
⇤ Evaluation with 3 real topologies:
Abilene (11 nodes), Switch (42), US Carrier (158)
⇤ Increasing the security by 80%
changes < 20% of the paths (Switch)
⇤ > 90% of the link failures can be precisely tracked back
This work was partly supported by armasuisse Science and Technology (S+T) under the Zurich Information Security and Privacy (ZISC) grant.
Join me at the poster session