Reconciling Confidentiality with Cooperation in Interdomain Routing

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 Buffet: R u still richer than me, kid? Confidential Information. Why? Leaks information about Future investments Who is richer? Warren Buffet Bill Gates Gates G=$40 Billion B=$31 Billion Possible Information Leakage: Buffet knows Gates is worth >$31 Billion Gates knows Buffet is worth <$40 Billion

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 Peering Link 1 A B 15Mbps 12Mbps Destination D 11Mbps Peering Link 2

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] Peering Link 1 A B Destination D 11Mbps 14Mbps 10Mbps Peering Link 2

15. 1.Proposed Solution • Confidential information – • A’s proposedchanges • B’savailable 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 Destination D A B Provider Q Provider P Source C

18. 2.Customer-defined Exports • Source C wants redundant paths to destination and wants provider P to export B’s route instead of A Destination D A B Provider Q Provider P Source C

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 itprefers 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