1 Reconciling Confidentiality with Cooperation in Interdomain Routing Sridhar Machiraju SAHARA 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 BuffetBill 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 Billion Gates 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 g x (mod)p Encrypted Multiplication = Addition because (g a r x,r).(g b s x,s) = (g a+b (rs) x,rs) Encrypted Exponentiation = Multiplication because (g a r x,r) b = (g ab (r b ) x,r b ) 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 AB Peering Link 1 Peering Link 2 15Mbps 12Mbps Destination 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] AB Peering Link 1 Peering Link 2 10Mbps 14Mbps 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 AB Source C Destination D Provider P Provider 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 AB Source C Destination D Provider P Provider 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 (u 0,…,u n-1 ) and check for dispute wheel; AS u i defines b i =0 iff it prefers the next AS and check, using secure addition b i >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”, [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

27 Solution to Yao’s Problem In [Proproco03Solution], Buffet uses a public key K pub and private key K pri Gates chooses random number r and sends E(K pub,r)-G=X to Buffet Buffet uses K pri to calculate D(X+1) … D(X+B), D(X+B+2) … and sends these to Gates If G<B, the G th number would be r

28 2.Formally, Provider P has a set of cost C d,p to use its peer p to reach destination d over the existing peer which reflect its peering arrangements and need to be confidential Customer C chooses a subset of changes from {(destination,peer)} and wants to determine if the total cost < M, its maximum cost Use a similar technique as earlier