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