Академический Документы
Профессиональный Документы
Культура Документы
$
Local
ISP
Sharon Goldberg g
Princeton University
Based on work with:
Boaz Barak, Shai Halevi, Aaron Jaggard, Vijay Ramachandran,
Jennifer
Princeton Rexford,
University Eran Tromer, Rebecca Wright, and David Xiao
The Internet (1)
Th Internet
The I t t is
i a collection
ll ti off Autonomous
A t Systems
S t (AS).
(AS)
Princeton
AT&T
IBM
Local
ISP
Comcast
Princeton
AT&T
IBM
Local
ISP
Comcast
Local ISP
Different Failure Models & Formal Techniques
Honest
• Follows the protocol
The Internet
was designed
Benign / Fail-Stop for this.
• Stops responding
$
Game Theory
Rational (Selfish)
• Deviates from protocol for personal g
gain
Cryptography
Adversarial
• Actively tries to “break” the protocol
Research Approach
$
Ite
System
(Goal)
Evaluate Protocol
Implement /
Characterize
Ch t i
Tech transfer
Security vs Efficiency
Secure Routing on the Internet
Princeton
AT&T
IBM
Local
ISP
Comcast
$
Rational ASes Adversarial routers
[GXTBR, SIGMETRICS’08]
[GHJRW, SIGCOMM’08]
[BGX, EUROCRYPT’08]
Known control-
control-plane
New data-
data-plane
protocols, like Secure BGP
protocols & characterization
☺
Part I : The Control Plane
AT&T $ Princeton
IBM
$ Local
ISP Local Val
Valuation:
ation
Comcast Comcast, IBM
AT&T, IBM
IBM
Comcast, IBM
Forwarding: Node use single outgoing link for all traffic to destination.
Valuations: Usually based on economic relationships.
Here, we assume they are fixed at “beginning of game”
BGP: The Internet Routing Protocol (2)
P th b
Paths t
between A t
Autonomous S t
Systems (AS
(ASes)) are
set up via the Border Gateway Protocol (BGP).
AT&T, IBM
$
Princeton
AT&T $
IBM
Local Princeton Valuat’n:
ISP Local AT&T
Local, AT&T, IBM
Comcast AT&T, IBM
Local, Comcast, IBM
Forwarding: Node use single outgoing link for all traffic to destination.
Valuations: Usually based on economic relationships.
Here, we assume they are fixed at “beginning of game”
Our desired security goal…
Princeton
AT&T
IBM
Local Princeton Valuat’n:
ISP Local AT&T
Local, AT&T, IBM
Comcast AT&T, IBM
Local, Comcast, IBM
Princeton
AT&T
IBM $
Local Princeton Valuat’n:
ISP Local AT&T
Local, AT&T, IBM
Comcast AT&T, IBM
Local, Comcast, IBM
Public Comcast:
Key (IBM)
Infrastructure
Local: (Comcast, IBM)
Princeton: ((Local,, Comcast,, IBM))
Princeton
AT&T
IBM
Local
ISP
Comcast
Comcast: (IBM)
Comcast: (IBM)
Public Comcast:
Key (IBM)
Infrastructure
Local: (Comcast, IBM)
Princeton: ((Local,, Comcast,, IBM))
Princeton
AT&T
IBM
Local
ISP
Comcast
Comcast: (IBM)
If we assume nodes are(IBM)
Comcast: rational,
do we get securityLocal:
from (Comcast,
“Secure IBM)
BGP”?
Y
Yes - For
F certain
t i utility
tilit models
d l ((prior
i work)
k)
Public Key Signature: Anyone who knows IBM’s
public keyNo - For more
can verify realistic was
the message onessent
(ourby
work)
IBM.
The “No Attractions” model of utility…
Model of utility in prior work:
. Utility of outgoing Utility of attracted
Utility of AS = (data-plane)
( p ) path
p + incoming g traffic
Princeton
AT&T
IBM
Local
ISP Local Valuatio’n:
Comcast Comcast, IBM
AT&T IBM
AT&T,
No Attractions [LSZ]
AT&T $ $
Princeton
IBM
$ Local $
ISP
Local Valuat’n:
Attract: Princeton
Comcast
Comcast IBM
Comcast,
Valuat’n:
AT&T, IBM
Comcast, IBM
More realistically models AT&T, IBM
payment structure.
Do control plane & data plane match?
Utility
y Secure
Model BGP
No Attractions [LSZ]
Attractions X
?
Local: (Comcast,
(AT&T, IBM)IBM)
Princeton: (Local,
(Local AT&T,
AT&T
Comcast,
Comcast
IBM)IBM)
AT&T: (IBM)
Princeton
AT&T
IBM $
Local Princeton Valuat’n:
ISP Local, AT&T, IBM
Comcast
☺ AT&T, IBM
Local, Comcast, IBM
Attract: Princeton
Comcast: (IBM) Valuation:
Comcast, IBM
Local: (Comcast, IBM) AT&T, IBM
Do control plane & data plane match?
Utility
y Secure Next-hopp
Model BGP Policy
Attractions X
? ?
N t h policy:
Next-hop li Valuations
V l ti d
depend l on 1stt
d only
AS to receive traffic.
Princeton
AT&T
IBM $
Local Princeton
Princeton Valuat’n:
Valuat’n:
ISP Local, AT&T, IBM
Local, * , IBM
Comcast AT&T, IBM
AT&T,
Local, *, IBM IBM
AT&T Comcast,
Attract: Princeton
Valuation:
Comcast, IBM
AT&T, IBM
Do control plane & data plane match?
Secure Next-hopp
Att ti
Attractions
BGP Policy
Attractions X X
?
N th
Next-hop li
policy, ((naïve)
ï ) iintuition:
t iti
If a uses a next-hop policy, nothing m says affects a.
Blah Blah
blah blah Surprisingly,
S i i l
intuition fails
m, *, dest
…. (again).
(aga )
…. a m
Counterexample: Next-hop policy is not sufficient! (1)
Attract Princeton
(on direct link only)
Value: IBM
Sprint, *, IBM
$
IBM
Greedy
AT&T
ISP
$
$ Princeton
Sprint, *, IBM
Greedy, *, IBM
$ Sprint $
Greedy, *, IBM
IBM
Counterexample: Next-hop policy is not sufficient! (2)
Attract Princeton
(on direct link only)
Value: IBM
Sprint, *, IBM Greedy, IBM
Attract Princeton
(on direct link only)
Value: IBM
Sprint, *, IBM Greedy, IBM
☺
Greedy Greedy, Princeton, IBM
AT&T
IBM ISP
Sprint, *, IBM
Princeton
Greedy, *, IBM
IBM
Sprint
☺
Greedy Greedy, Princeton, IBM
AT&T
IBM ISP
Sprint, *, IBM
Princeton
Greedy, *, IBM
Sprint
Greedy, *, IBM
IBM
Do control plane & data plane match?
Secure Next-hopp
Att ti
Attractions
BGP Policy
Attractions X * X
Our Main Theorem
For a network with traffic attraction where all nodes have
Proof Idea:
1. Assume some node gets higher utility by lying
p
2. Show some node must have announced a false loop.
3. Contradiction if nodes use Secure BGP.
Our Main Theorem
For a network with traffic attraction where all nodes have
Attractions X * X
Bob
Alice
Bob ack
ack
Alice
Alice
ping
Eve
Bob
Alice
Eve
Argued
g by
y reduction to one-wayy functions.
Bob
Alice
Eve
B
Argued
Limited
with
incentives
Impagliazzo-Rudich
to deploy these
styleprotocols
black boxinseparation.
the Internet.
Efficient & Secure Detection : Protocol
key k , key k ,
Alice Bob
+1
A 0 0 10 -2
2 1 0 1 0 3 1
0 0 0 01 -1
1 1 0 -1
1 0 43 0
B
Hash each packet fk(d) = index Hash each packet fk(d) = index
Update sketch A[index] += 1 Update sketch B[index] += 1
Send authenticated (MAC’d) sketch
Take difference sketch X = A-B
MACC and send
Decide btwn > 1% and < 0.5% loss:
• Compute the ℓ2-norm ΣXi2
• Raise an alarm iff norm > 0.66%
Refresh hash key & Repeat Refresh hash key & Repeat
Efficient & Secure Detection : Summary
key k key k
Alice Bob
+1
A 0 0 0 -2
2 1 0 1 0 3 0 0 0 0 -1
1 1 0 -1
1 0 3 0
B
Our protocol requires: Pkts Sketch
• O(log(#
O(l (# packets))
k t )) storage
t att Alice
Ali & Bob
B b 106 170 Bytes
• compute one hash / packet at Alice & Bob 107 200 Bytes
• no traffic modification
• 2 extra packets (communication) 108 235 Bytes
• pairwise keys at Alice & Bob 109 270 Bytes
Local
ISP
Princeton University