reconciling confidentiality with cooperation in interdomain routing
DESCRIPTION
Reconciling Confidentiality with Cooperation in Interdomain Routing. Sridhar Machiraju SAHARA Retreat, January 2004. Outline. Motivation and Problem Statement Confidential Information in Routing Introduction to Secure Computation 3 Problems Illustrating Our Techniques - PowerPoint PPT PresentationTRANSCRIPT
1
Reconciling Confidentiality with Cooperation in Interdomain Routing
Sridhar MachirajuSAHARA Retreat, January 2004
2
Outline• Motivation and Problem Statement• Confidential Information in Routing• Introduction to Secure Computation• 3 Problems Illustrating Our Techniques• Discussion and Concluding Remarks• References
3
Motivation• BGP problems due to lack of information
– Traffic engineering performed by one AS may not cause flows to encounter congestion in other ASes
– Policies of ASes could conflict resulting in routes that continuously oscillate
– Hop-by-hop nature and no information about delay etc. cause poor route selection
• Limited information exchange because of concerns about scalability and confidentiality
4
Problem Statement• Can ASes cooperate with each other
without having to reveal their confidential information, provided that other concerns such as scalability are assuaged?
• We consider the following scenarios:– Traffic engineering that is safe for peers– Better route selection at stub ASes– Prevention of policy conflict-induced
divergence
5
Outline• Motivation and Problem Statement• Confidential Information in Routing• Introduction to Secure Computation• 3 Problems Illustrating Our Techniques• Discussion and Concluding Remarks• References
6
Confidential Information in Routing
• Topology: relatively stable, traceroutes can determine topology [Spring02Measuring]
• Capacities and delays: relatively stable, pathchar can calculate these to some extent; not done for a complete AS
• Available bandwidth,loss rate,jitter: fast changing, can reasonably estimate end-to-end properties [Strauss03Measurement]
7
Confidential Information in Routing(2)
• Connectivity graph: stable, easy to find [Subramanian02Characterizing]
• Traffic engineering policies: maximum utilization tolerable for internal links etc., hard to deduce(at least till now)
• Peering agreements: cost of peering, max. amount of traffic to be exchanged, hard to deduce(at least till now)
• BGP Configuration: import,export policies, local prefs, MEDs etc., can deduce many of these
8
Information Leakage• ICMP tools and Routeviews responsible
for most of the information leakage• Some amount of information leakage is
inevitable from end-to-end measurements, e.g., loss rates, jitter etc.
• We define 100% success as – “Information leakage must be restricted to what can be deduced from the outcome”
9
Yao’s (B)Millionaires Problem
Warren Buffet Bill Gates
Buffet: R u still richer than me, kid?
B=$31 Billion G=$40 Billion
Confidential Information.Why? Leaks information about
Future investments
Who is richer?
Possible Information Leakage: Buffet knows Gates is worth >$31 BillionGates knows Buffet is worth <$40 Billion
Gates
10
Outline• Motivation and Problem Statement• Confidential Information in Routing• Secure Computational Techniques• 3 Problems Illustrating Our Techniques• Discussion and Concluding Remarks• References
11
Secure Multiparty Computations
• Hardness of discrete logarithm: Given large p and random g and large random x, it is hard to find e given g(mod)p and gx(mod)p
• Encrypted Multiplication = Addition because (garx,r).(gbsx,s) = (ga+b(rs)x,rs)
• Encrypted Exponentiation = Multiplication because (garx,r)b = (gab(rb)x,rb)
• Subtraction easy; division is much harder
12
Outline• Motivation and Problem Statement• Confidential Information in Routing• Introduction to Secure Computation• 3 Problems Illustrating Our
Techniques• Discussion and Concluding Remarks• References
13
1.Prevent Congestion in Peer• A and B peer with each other at two
places• A changes its input traffic matrix to B
A B
Peering Link 1
Peering Link 2
15Mbps12MbpsDestination D
11Mbps
14
1.Prevent Congestion in Peer• A and B peer with each other at two
places• A changes its input traffic matrix to B• Will this encounter congestion in B?• Problem introduced in [Winick02Traffic]
A B
Peering Link 1
Peering Link 210Mbps14Mbps
11Mbps
Destination D
15
1.Proposed Solution• Confidential information –
– A’s proposed changes – B’s available bandwidth on bottlenck links
• Naïve methods -– A informs B of proposed changes to offered
traffic– B informs A of bottlenecks and available
bandwidth on them• Use secure multiparty computations to
check if [available bandwidth–requested bandwidth<0] on each bottleneck
16
Deployment Issues• Easy deployment because it only needs
the two ASes to run the algorithm• Necessary information easily available
from existing network operations center• Scalable because A’s changes to a few
“heavy-hitter” destination prefixes only need to be considered [Winick02Traffic]
17
2.Customer-defined Exports• Source C wants redundant paths to
destination and wants provider P to choose B’s route instead of A
A B
Source C
Destination D
Provider PProvider Q
18
2.Customer-defined Exports• Source C wants redundant paths to
destination and wants provider P to export B’s route instead of A
A B
Source C
Destination D
Provider PProvider Q
19
2.Overview of Solution• Confidential information-
– P: Cost of each change in export policy – C: Changes being considered and maximum
allowable cost• In general, C does not want to reveal
changes being considered until they are approved
• Again, secure multiparty computations can be used to negotiate
20
3.Policy Safety• BGP policies can diverge, e.g., A prefers
B prefers C prefers A to reach D• [Griffin02Stable] shows that
determining dispute wheels is sufficient to prevent policy-created divergence; this is known to be NP-complete
• Using local configurations that use valley-free paths is an alternative approach, but requires some global knowledge; our techniques can be used
21
3.Determining Dispute Wheels
• Assume that local_preference depends on neighboring ASes only
• Continuously, choose a random set of ASes (u0,…,un-1) and check for dispute wheel; AS ui defines bi=0 iff it prefers the next AS and check, using secure addition bi>0
• Scalability: Might experience wide-area latencies; could use public peering points where many ASes are present
22
Outline• Motivation and Problem Statement• Confidential Information in Routing• Introduction to Secure Computation• 3 Problems Illustrating Our Techniques• Discussion and Concluding Remarks• References
23
Combating Malice• Malicious Peers: We assume an “honest-
but-curious” model, i.e., protocol is followed by all but past messages are stored. Changing keys regularly might be a solution
• What if a peer provides wrong inputs? Random outputs, confidentiality preserved
• Problem-specific special inputs: e.g., for customer-defined exports, make just 1 change and determine the range of provider’s cost
24
Conclusions• Inter-domain routing could benefit a lot
from cooperation which is hindered by confidentiality requirements
• We illustrate techniques to show this for managing, optimizing and debugging routing.
• Future Work: Lots – solve more problems, measure overhead, quantify information leakage, detect malicious behavior
25
References (1)• [Spring02Measuring]-“Measuring ISP
Topologies with Rocketfuel”, N. Spring, R. Mahajan and D. Wetherall, SIGCOMM ’02
• [Strauss03Measurement]–”A Measurement Study of Available Bandwidth Estimation Tools”, J. Strauss et. al. , IMC ’03
• [Subramanian02Characterizing]-”Characte-rizing the Internet Hierarchy from Multiple Vantage Points”, L. Subramanian et. al, INFOCOM ‘02
26
References (2)• [Proprocos03Solution]-”Solution to the
Millionaire’s Problem”, http://www.proproco.co.uk/million.html
• [Winick02Traffic]-”Traffic Engineering Between Neighboring Domains”, J. Winick et al., July 2002, Unpublished Report
• [Griffin02Stable]-”The Stable Paths Problem and Interdomain Routing”,T. Griffin et. al., IEEE/ACM TON, April 2002