[144214] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Do Not Complicate Routing Security with Voodoo Economics

daemon@ATHENA.MIT.EDU (Sharon Goldberg)
Mon Sep 5 16:05:32 2011

In-Reply-To: <61788FCE-4637-4D54-9096-F5F3346CD5DE@cc.gatech.edu>
From: Sharon Goldberg <goldbe@cs.bu.edu>
Date: Mon, 5 Sep 2011 16:04:21 -0400
To: Nick Feamster <feamster@cc.gatech.edu>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

Nick Feamster wrote:
> 2. I question what fraction of routing decisions come down to a blind tie=
break---nearly all of them are likely to be driven by some other considerat=
ion (reliability, cost, etc.). =A0Our paper details a richer economic model=
 by which ASes actually select paths, for example, but it's still unclear t=
o me how coarse or fine-grained route selection really is in practice, and =
to what extent more complicated contracts have evolved. =A0I wonder how com=
mon "blind tiebreaking" is in BGP, in real networks; the approach in Sharon=
's paper definitely may overstate how common that is if route selection con=
siderations commonly involve things that are not visible in the AS graph (e=
.g., traffic ratios, congestion, performance), but academics could really b=
enefit from some more insight into how rich these decisions are in practice=
.

We think a key point is getting lost here.

Routing policies affect our result in the following crucial way --
they determine the size of ASes' "tiebreak sets" (section 6.6).  A
tiebreak set is a set of  "equally good routes" that an source AS has
to a destination AS; in our model, an AS should prefer to route along
the _secure_ routes in its tiebreak set. Simply put, with a larger
tiebreak set, there should be more competition over customer traffic,
and thus more widespread S*BGP deployment.

In our simulations we assumed that tiebreak sets were determined by
Local-Pref (economic considerations) and AS-Path considerations.   In
practice, tiebreak sets could be larger (e.g., if ASes prefer shorter
paths over customer paths) or smaller (e.g.,  if intradomain
considerations, like hot potato routing, affect tiebreak sets) than
those in our simulations.  Like Nick said, this is a place where more
data from the ops community would be helpful to help us figure out how
big tiebreak sets really are.

However, the key point we want to emphasize is that in the simulations
we ran, the tiebreak sets are actually quite small:
1) The size of the average AS tiebreak set in our simulations is only
1.18; which mean that 80% of tiebreak sets have only one path, see
also Figure 8.
2) Security does not play a role in the vast majority (96%) of routing
decisions made in our simulations (Section 6.7).
In other words, S*BGP deployment can be driven even by a fairly small
amount of competition for customer traffic.

> 3. I think the discussion on the list so far misses what I see as the cen=
tral question about the economic assumptions in that paper. =A0The paper as=
sumes that all destinations are equally valuable, which we know is not the =
case. =A0This implicitly (and perhaps mistakenly?) shifts the balance of po=
wer to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., G=
oogle). =A0In practice, ISPs may be willing to spend significant amounts of=
 money to reach certain destinations or content (some destinations are more=
 valuable than others... e.g., Google). =A0If the most "valuable" destinati=
ons deployed S-BGP and made everyone who wanted to connect to them deploy i=
t, that would be more likely to succeed than the approach taken in the pape=
r, I think.

Our paper does not assume all destinations are equally valuable.

1) As mentioned in our response to Randy, we weight content
providers more heavily  (see Section 6.8.1; we ran experiments where
the content providers collectively source 10%, 20%, 33% or 50% of
Internet traffic).

2) From Section 6.8.1: "We test the robustness of our results... by
modeling traffic locality [the idea that ASes are likely to send more
traffic to ASes that are closer to them]..." Section 6.8.2 shows our result=
s are
insensitive to this assumption.

Sincerely,
Phillipa Gill, Michael Schapira, and Sharon Goldberg

> On Sep 5, 2011, at 11:36 AM, Joe Maimon wrote:
>
>>
>>
>> Owen DeLong wrote:
>>>
>>> On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
>>>
>>>>
>>>>>
>>>>> One could argue that rejecting routes which you previously had no way=
 to
>>>>> know you should reject will inherently alter the routing system and t=
hat this
>>>>> is probably a good thing.
>>>>
>>>> Good point. =A0Also, "tie breaking" in favor of signed-and-verified ro=
utes over not-signed-and-verified routes does not necessarily affect your t=
raffic "positively or negatively" -- rather, if you are letting an arbitrar=
y final tie break make the decision anyway, you are arguably *neutral* abou=
t the outcome...
>>>>
>>>> -- Jen
>>>
>>> This is true in terms of whether you care or not, but, if one just look=
s at whether it changes the content of the FIB or not, changing which arbit=
rary tie breaker you use likely changes the contents of the FIB in at least=
 some cases.
>>>
>>> The key point is that if you are to secure a previously unsecured datab=
ase such as the routing table, you will inherently be changing the contents=
 of said database, or, your security isn't actually accomplishing anything.
>>>
>>> Owen
>>>
>>
>>
>> Except if you believe we have been lucky until now and security is all a=
bout the future where we may be less lucky.
>>
>> What I would be interested in seeing is a discussion on whether any anti=
-competitive market distortion incentives exist for large providers in adop=
ting secured BGP. We might be lucky there too.
>>
>> Perhaps this will finally help solve the routing slot scalability proble=
m. Might also jumpstart LISP. Which may put some more steam into v6. Welcom=
e to the brave new internet.
>>
>> Good for everyone, right?
>>
>> Are you feeling lucky?
>>
>>
>> Joe
>>
>
>
>



--=20
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe


home help back first fref pref prev next nref lref last post