Re: Do Not Complicate Routing Security with Voodoo Economics

[Dobbins, Roland]

On Sep 4, 2011, at 5:02 PM, Randy Bush wrote:

> Will the benefits of security - no more YouTube incidents, etc. - be 
> perceived as worth having one's routing at the whim of an non-operational 
> administrative monopoly?

Given recent events in SSL CA-land, how certain are we that the putative 
security benefits are all that great?  Not to mention the near-certainty of a 
BGP version of 'PROTECT IP', once the mechanisms are in place.

Same applies to DNSSEC, of course.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Do Not Complicate Routing Security with Voodoo Economics

[Neil J. McRae]

Well said Randy - the previous paper is flawed and if the findings where true 
you would wonder how anyone ever created a viable online business.

Neil

Sent from my iPhone

On 4 Sep 2011, at 11:03, "Randy Bush"  wrote:

> [ http://archive.psg.com/110904.broadside.html ]
> 
>Do Not Complicate Routing Security with Voodoo Economics
>  a broadside
> 
> A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
> Goldberg[1] drew a lot of 'discussion' from the floor.  But that
> discussion missed significant problems with this work.  I raise this
> because of fear that uncritical acceptance of this work will be used as
> the basis for others' work, or worse, misguided public policy.
> o The ISP economic and incentive model is overly naive to the point of
>   being misleading, 
> o The security threat model is unrealistic and misguided, and
> o The simulations are questionable.
> 
> Basic ISP economics are quite different from those described by the
> authors.  Above the tail links to paying customers, the expenses of
> inter-provider traffic are often higher than the income, thanks to the
> telcos' race to the bottom.  In this counter-intuitive world, transit
> can often be cheaper than peering.  I.e. history shows that in the rare
> cases where providers have been inclined to such games, they usually
> shed traffic not stole it, the opposite of what the paper presumes.  The
> paper also completely ignores the rise of the content providers as
> described so well in SIGCOMM 2010 by Labovitz et alia[2]
> 
> It is not clear how to ‘fix’ the economic model, especially as[3] says
> you can not do so with rigor.  Once one starts, e.g. the paper may lack
> Tier-N peering richness which is believed to be at the edges, we have
> bought into the game for which there is no clear end.
> 
> But this is irrelevant, what will motivate deployment of BGP security is
> not provider traffic-shifting.  BGP security is, as its name indicates,
> about security, preventing data stealing (think banking
> transactions[4]), keeping miscreants from originating address space of
> others (think YouTube incident) or as attack/spam sources, etc.
> 
> The largest obstacle to deployment of BGP security is that the
> technology being deployed, RPKI-based origin validation and later
> BGPsec, are based on an X.509 certificate hierarchy, the RPKI.  This
> radically changes the current inter-ISP web of trust model to one having
> ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
> Will the benefits of security - no more YouTube incidents, etc. - be
> perceived as worth having one's routing at the whim of an
> non-operational administrative monopoly?  Perhaps this is the real
> economic game here, and will cause a change in the relationship between
> the operators and the RIR cartel.
> 
> The paper's simulations really should be shown not to rely on the
> popular but highly problematic3 Gao-Rexford model of inter-provider
> relationships, that providers prefer customers over peers (in fact, a
> number of global Tier-1 providers have preferred peers for decades), and
> that relationships are valley free, which also has significant
> exceptions.  Yet these invalid assumptions may underpin the simulation
> results.
> 
> ---
> 
> Randy Bush 
> Dubrovnik,  2011.9.4
> 
> [1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
> Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
> August 2011.
> http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf
> 
> [2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
> F. Jahanian, “Internet inter-domain traffic,” in SIGCOMM '10:
> Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.
> 
> [3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
> Lessons from 10 Years of Measuring and Modeling the Internet's
> Autonomous Systems, IEEE Journal on Selected Areas in Communications,
> Vol. 29, No. 9, pp. 1-12, Oct. 2011.
> https://archive.psg.com/111000.TenLessons.pdf
> 
> [4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
> In The Middle Attack, Defcon 16, August, 2008.
> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
> 
> 

Re: Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

> the previous paper is flawed and if the findings where true you would
> wonder how anyone ever created a viable online business.

to me honest, what set me off was 

   http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1

describing, among others, a routing working group of an fcc
"communications security, reliability and interoperability council"

i.e. these folk plan to write policy and procedures for operators, not
just write publish or perish papers.

randy

Re: Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

>> the previous paper is flawed and if the findings where true you would
>> wonder how anyone ever created a viable online business.
> 
> to me honest, what set me off was 
> 
>http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1
> 
> describing, among others, a routing working group of an fcc
> "communications security, reliability and interoperability council"
> 
> i.e. these folk plan to write policy and procedures for operators, not
> just write publish or perish papers.

apologies.  dorn caught my error

http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1.pdf

randy

Re: Do Not Complicate Routing Security with Voodoo Economics

[Patrick W. Gilmore]

Mostly excellent thoughts, well documented.  I have a question about this 
statement though:

> in fact, a number of global Tier-1 providers have preferred peers for decades

I assume you mean for a very limited subset of their customers?  I've checked 
routing on well over half the transit free networks on the planet, and for the 
small number of customers I was researching, they definitely preferred customer 
routes over peering.

-- 
TTFN,
patrick


On Sep 4, 2011, at 6:02 AM, Randy Bush wrote:

> [ http://archive.psg.com/110904.broadside.html ]
> 
>   Do Not Complicate Routing Security with Voodoo Economics
> a broadside
> 
> A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
> Goldberg[1] drew a lot of 'discussion' from the floor.  But that
> discussion missed significant problems with this work.  I raise this
> because of fear that uncritical acceptance of this work will be used as
> the basis for others' work, or worse, misguided public policy.
> o The ISP economic and incentive model is overly naive to the point of
>   being misleading, 
> o The security threat model is unrealistic and misguided, and
> o The simulations are questionable.
> 
> Basic ISP economics are quite different from those described by the
> authors.  Above the tail links to paying customers, the expenses of
> inter-provider traffic are often higher than the income, thanks to the
> telcos' race to the bottom.  In this counter-intuitive world, transit
> can often be cheaper than peering.  I.e. history shows that in the rare
> cases where providers have been inclined to such games, they usually
> shed traffic not stole it, the opposite of what the paper presumes.  The
> paper also completely ignores the rise of the content providers as
> described so well in SIGCOMM 2010 by Labovitz et alia[2]
> 
> It is not clear how to ‘fix’ the economic model, especially as[3] says
> you can not do so with rigor.  Once one starts, e.g. the paper may lack
> Tier-N peering richness which is believed to be at the edges, we have
> bought into the game for which there is no clear end.
> 
> But this is irrelevant, what will motivate deployment of BGP security is
> not provider traffic-shifting.  BGP security is, as its name indicates,
> about security, preventing data stealing (think banking
> transactions[4]), keeping miscreants from originating address space of
> others (think YouTube incident) or as attack/spam sources, etc.
> 
> The largest obstacle to deployment of BGP security is that the
> technology being deployed, RPKI-based origin validation and later
> BGPsec, are based on an X.509 certificate hierarchy, the RPKI.  This
> radically changes the current inter-ISP web of trust model to one having
> ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
> Will the benefits of security - no more YouTube incidents, etc. - be
> perceived as worth having one's routing at the whim of an
> non-operational administrative monopoly?  Perhaps this is the real
> economic game here, and will cause a change in the relationship between
> the operators and the RIR cartel.
> 
> The paper's simulations really should be shown not to rely on the
> popular but highly problematic3 Gao-Rexford model of inter-provider
> relationships, that providers prefer customers over peers (in fact, a
> number of global Tier-1 providers have preferred peers for decades), and
> that relationships are valley free, which also has significant
> exceptions.  Yet these invalid assumptions may underpin the simulation
> results.
> 
> ---
> 
> Randy Bush 
> Dubrovnik,  2011.9.4
> 
> [1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
> Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
> August 2011.
> http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf
> 
> [2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
> F. Jahanian, “Internet inter-domain traffic,” in SIGCOMM '10:
> Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.
> 
> [3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
> Lessons from 10 Years of Measuring and Modeling the Internet's
> Autonomous Systems, IEEE Journal on Selected Areas in Communications,
> Vol. 29, No. 9, pp. 1-12, Oct. 2011.
> https://archive.psg.com/111000.TenLessons.pdf
> 
> [4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
> In The Middle Attack, Defcon 16, August, 2008.
> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
> 

Re: Do Not Complicate Routing Security with Voodoo Economics

[deleskie]

I have worked for more then one transit free network, and have work with people 
from (most) of the rest, we always prefer cust over peer, every time.

-jim
Sent from my BlackBerry device on the Rogers Wireless Network

-Original Message-
From: "Patrick W. Gilmore" 
Date: Sun, 4 Sep 2011 09:51:12 
To: North American Network Operators' Group
Subject: Re: Do Not Complicate Routing Security with Voodoo Economics

Mostly excellent thoughts, well documented.  I have a question about this 
statement though:

> in fact, a number of global Tier-1 providers have preferred peers for decades

I assume you mean for a very limited subset of their customers?  I've checked 
routing on well over half the transit free networks on the planet, and for the 
small number of customers I was researching, they definitely preferred customer 
routes over peering.

-- 
TTFN,
patrick


On Sep 4, 2011, at 6:02 AM, Randy Bush wrote:

> [ http://archive.psg.com/110904.broadside.html ]
> 
>   Do Not Complicate Routing Security with Voodoo Economics
> a broadside
> 
> A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
> Goldberg[1] drew a lot of 'discussion' from the floor.  But that
> discussion missed significant problems with this work.  I raise this
> because of fear that uncritical acceptance of this work will be used as
> the basis for others' work, or worse, misguided public policy.
> o The ISP economic and incentive model is overly naive to the point of
>   being misleading, 
> o The security threat model is unrealistic and misguided, and
> o The simulations are questionable.
> 
> Basic ISP economics are quite different from those described by the
> authors.  Above the tail links to paying customers, the expenses of
> inter-provider traffic are often higher than the income, thanks to the
> telcos' race to the bottom.  In this counter-intuitive world, transit
> can often be cheaper than peering.  I.e. history shows that in the rare
> cases where providers have been inclined to such games, they usually
> shed traffic not stole it, the opposite of what the paper presumes.  The
> paper also completely ignores the rise of the content providers as
> described so well in SIGCOMM 2010 by Labovitz et alia[2]
> 
> It is not clear how to ‘fix’ the economic model, especially as[3] says
> you can not do so with rigor.  Once one starts, e.g. the paper may lack
> Tier-N peering richness which is believed to be at the edges, we have
> bought into the game for which there is no clear end.
> 
> But this is irrelevant, what will motivate deployment of BGP security is
> not provider traffic-shifting.  BGP security is, as its name indicates,
> about security, preventing data stealing (think banking
> transactions[4]), keeping miscreants from originating address space of
> others (think YouTube incident) or as attack/spam sources, etc.
> 
> The largest obstacle to deployment of BGP security is that the
> technology being deployed, RPKI-based origin validation and later
> BGPsec, are based on an X.509 certificate hierarchy, the RPKI.  This
> radically changes the current inter-ISP web of trust model to one having
> ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
> Will the benefits of security - no more YouTube incidents, etc. - be
> perceived as worth having one's routing at the whim of an
> non-operational administrative monopoly?  Perhaps this is the real
> economic game here, and will cause a change in the relationship between
> the operators and the RIR cartel.
> 
> The paper's simulations really should be shown not to rely on the
> popular but highly problematic3 Gao-Rexford model of inter-provider
> relationships, that providers prefer customers over peers (in fact, a
> number of global Tier-1 providers have preferred peers for decades), and
> that relationships are valley free, which also has significant
> exceptions.  Yet these invalid assumptions may underpin the simulation
> results.
> 
> ---
> 
> Randy Bush 
> Dubrovnik,  2011.9.4
> 
> [1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
> Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
> August 2011.
> http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf
> 
> [2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
> F. Jahanian, “Internet inter-domain traffic,” in SIGCOMM '10:
> Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.
> 
> [3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
> Lessons from 10 Years of Measuring and Modeling the Internet's
> Autonomous Systems, IEEE Journal on Selected Areas in Communications,
> Vol. 29, No. 9, pp. 1-12, Oct. 2011.
> https://archive.psg.com/111000.TenLessons.pdf
> 
> [4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
> In The Middle Attack, Defcon 16, August, 2008.
> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
> 

Re: Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

> I have worked for more then one transit free network, and have work
> with people from (most) of the rest, we always prefer cust over peer,
> every time.

again, more than one of the world's largest providers prefer peers.  and
even if they wanted to change, it would be horribly anti-pola to the
affected customers, like white hot wires.  and one just does not do that
to customers.

randy

RE: Do Not Complicate Routing Security with Voodoo Economics

[Leigh Porter]

> -Original Message-
> From: Randy Bush [mailto:ra...@psg.com]
> Sent: 04 September 2011 15:01
> To: deles...@gmail.com
> Cc: North American Network Operators' Group
> Subject: Re: Do Not Complicate Routing Security with Voodoo Economics
> 
> > I have worked for more then one transit free network, and have work
> > with people from (most) of the rest, we always prefer cust over peer,
> > every time.
> 
> again, more than one of the world's largest providers prefer peers.
> and
> even if they wanted to change, it would be horribly anti-pola to the
> affected customers, like white hot wires.  and one just does not do
> that
> to customers.
> 
> randy

Presumably you can change that behaviour with communities?



--
Leigh Porter


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Do Not Complicate Routing Security with Voodoo Economics

[Patrick W. Gilmore]

On Sep 4, 2011, at 9:59 AM, Randy Bush wrote:

>> I have worked for more then one transit free network, and have work
>> with people from (most) of the rest, we always prefer cust over peer,
>> every time.
> 
> again, more than one of the world's largest providers prefer peers.  and
> even if they wanted to change, it would be horribly anti-pola to the
> affected customers, like white hot wires.  and one just does not do that
> to customers.

I repeat, you are obviously talking about a small subset of customers, right?  
Please clarify.

Because I know customers of all 14 transit free networks, and these customers 
all believe the network is preferring their routes unless the customer sends a 
community to override that preference.

-- 
TTFN,
patrick

Re: Do Not Complicate Routing Security with Voodoo Economics

[jim deleskie]

While I can think of some corner cases for this, ie you have a
satellite down link from one provider and fiber to anther.  I expect
this is not the norm for most networks/customers.

-jim

On Sun, Sep 4, 2011 at 10:59 AM, Randy Bush  wrote:
>> I have worked for more then one transit free network, and have work
>> with people from (most) of the rest, we always prefer cust over peer,
>> every time.
>
> again, more than one of the world's largest providers prefer peers.  and
> even if they wanted to change, it would be horribly anti-pola to the
> affected customers, like white hot wires.  and one just does not do that
> to customers.
>
> randy
>

Re: Do Not Complicate Routing Security with Voodoo Economics

[Jennifer Rexford]

>> to me honest, what set me off was
>> 
>>http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1
>> 
>> describing, among others, a routing working group of an fcc
>> "communications security, reliability and interoperability council"
>> 
>> i.e. these folk plan to write policy and procedures for operators, not
>> just write publish or perish papers.
> 
> apologies.  dorn caught my error
> 
> http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1.pdf

As one of the co-chairs of this working group, I'd like to chime in to clarify 
the purpose of this group.  Our goal is to assemble a group of vendors and 
operators (not "publish or perish" academics) to discuss and recommend 
effective strategies for incremental deployment of security solutions for BGP 
(e.g., such as the ongoing RPKI and BGP-SEC work).  It is not to design new 
security protocols or to "write policy and procedures for operators" -- that 
would of course be over-reaching and presumptuous.  The goal is specifically to 
identify strategies for incremental deployment of the solutions designed and 
evaluated by the appropriate technical groups (e.g., IETF working groups).  
And, while the SIGCOMM paper you mention is an example of such a strategy, it 
is just one single example -- and is by no means the recommendation of a group 
that is not yet even fully assembled yet.  The working group will debate and 
discuss a great many issues before suggesting any strategies, and those 
strategies would be the output of the entire working group.

 As for "publish or perish" academics, I doubt you'll find 
that the small set of academics who choose to go knee deep into operational 
issues do so because they are trying to optimize their academic careers... ;) 


-- Jen

Re: Do Not Complicate Routing Security with Voodoo Economics

[Neil J. McRae]

Jen,
What operators are involved? And who represents them specifically?

Neil.

On 04/09/2011 16:07, "Jennifer Rexford"  wrote:
>
>
>As one of the co-chairs of this working group, I'd like to chime in to
>clarify the purpose of this group.  Our goal is to assemble a group of
>vendors and operators (not "publish or perish" academics) to discuss and
>recommend effective strategies for incremental deployment of security
>solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>is not to design new security protocols or to "write policy and
>procedures for operators" -- that would of course be over-reaching and
>presumptuous.  The goal is specifically to identify strategies for
>incremental deployment of the solutions designed and evaluated by the
>appropriate technical groups (e.g., IETF working groups).  And, while the
>SIGCOMM paper you mention is an example of such a strategy, it is just
>one single example -- and is by no means the recommendation of a group
>that is not yet even fully assembled yet.  The working group will debate
>and discuss a great many issues before suggesting any strategies, and
>those strategies would be the output of the entire working group.
>
> As for "publish or perish" academics, I doubt you'll
>find that the small set of academics who choose to go knee deep into
>operational issues do so because they are trying to optimize their
>academic careers... ;) 
>
>-- Jen
>

Re: Do Not Complicate Routing Security with Voodoo Economics

[Jennifer Rexford]

Neil,

The group is being assembled right now, so we don't have a list as of yet. 

-- Jen


Sent from my iPhone

On Sep 4, 2011, at 11:32 AM, "Neil J. McRae"  wrote:

> Jen,
> What operators are involved? And who represents them specifically?
> 
> Neil.
> 
> On 04/09/2011 16:07, "Jennifer Rexford"  wrote:
>> 
>> 
>> As one of the co-chairs of this working group, I'd like to chime in to
>> clarify the purpose of this group.  Our goal is to assemble a group of
>> vendors and operators (not "publish or perish" academics) to discuss and
>> recommend effective strategies for incremental deployment of security
>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>> is not to design new security protocols or to "write policy and
>> procedures for operators" -- that would of course be over-reaching and
>> presumptuous.  The goal is specifically to identify strategies for
>> incremental deployment of the solutions designed and evaluated by the
>> appropriate technical groups (e.g., IETF working groups).  And, while the
>> SIGCOMM paper you mention is an example of such a strategy, it is just
>> one single example -- and is by no means the recommendation of a group
>> that is not yet even fully assembled yet.  The working group will debate
>> and discuss a great many issues before suggesting any strategies, and
>> those strategies would be the output of the entire working group.
>> 
>>  As for "publish or perish" academics, I doubt you'll
>> find that the small set of academics who choose to go knee deep into
>> operational issues do so because they are trying to optimize their
>> academic careers... ;) 
>> 
>> -- Jen
>> 
> 
> 

Re: Do Not Complicate Routing Security with Voodoo Economics

[Neil J. McRae]

maybe volunteers from the nanog community should contact you?

On 4 Sep 2011, at 16:45, "Jennifer Rexford"  wrote:

> Neil,
> 
> The group is being assembled right now, so we don't have a list as of yet. 
> 
> -- Jen
> 
> 
> Sent from my iPhone
> 
> On Sep 4, 2011, at 11:32 AM, "Neil J. McRae"  wrote:
> 
>> Jen,
>> What operators are involved? And who represents them specifically?
>> 
>> Neil.
>> 
>> On 04/09/2011 16:07, "Jennifer Rexford"  wrote:
>>> 
>>> 
>>> As one of the co-chairs of this working group, I'd like to chime in to
>>> clarify the purpose of this group.  Our goal is to assemble a group of
>>> vendors and operators (not "publish or perish" academics) to discuss and
>>> recommend effective strategies for incremental deployment of security
>>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>>> is not to design new security protocols or to "write policy and
>>> procedures for operators" -- that would of course be over-reaching and
>>> presumptuous.  The goal is specifically to identify strategies for
>>> incremental deployment of the solutions designed and evaluated by the
>>> appropriate technical groups (e.g., IETF working groups).  And, while the
>>> SIGCOMM paper you mention is an example of such a strategy, it is just
>>> one single example -- and is by no means the recommendation of a group
>>> that is not yet even fully assembled yet.  The working group will debate
>>> and discuss a great many issues before suggesting any strategies, and
>>> those strategies would be the output of the entire working group.
>>> 
>>>  As for "publish or perish" academics, I doubt you'll
>>> find that the small set of academics who choose to go knee deep into
>>> operational issues do so because they are trying to optimize their
>>> academic careers... ;) 
>>> 
>>> -- Jen
>>> 
>> 
>> 
> 

Re: Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

> As one of the co-chairs of this working group, I'd like to chime in to
> clarify the purpose of this group.  Our goal is to assemble a group of
> vendors and operators (not "publish or perish" academics) to discuss and
> recommend effective strategies for incremental deployment of security
> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
> is not to design new security protocols or to "write policy and
> procedures for operators"

This Working Group will recommend the framework for an industry
agreement regarding the adoption of secure routing procedures and
protocols based on existing work in industry and research. The
framework will include specific technical procedures and protocols. The
framework will be proposed in a way suitable for opt-in by large
Internet Service Providers...

randy

Re: Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

> While I can think of some corner cases for this, ie you have a
> satellite down link from one provider and fiber to anther.  I expect
> this is not the norm for most networks/customers.

what is it you do not understand about "more than one of the world's
largest providers?"  not in corner cases, but as core policy.

randy

Re: Do Not Complicate Routing Security with Voodoo Economics

[Anton Kapela]

+1

-Tk

On Sep 4, 2011, at 12:23 PM, "Neil J. McRae"  wrote:

> maybe volunteers from the nanog community should contact you?
>
> On 4 Sep 2011, at 16:45, "Jennifer Rexford"  wrote:
>
>> Neil,
>>
>> The group is being assembled right now, so we don't have a list as of yet.
>>
>> -- Jen
>>
>>
>> Sent from my iPhone
>>
>> On Sep 4, 2011, at 11:32 AM, "Neil J. McRae"  wrote:
>>
>>> Jen,
>>> What operators are involved? And who represents them specifically?
>>>
>>> Neil.
>>>
>>> On 04/09/2011 16:07, "Jennifer Rexford"  wrote:


 As one of the co-chairs of this working group, I'd like to chime in to
 clarify the purpose of this group.  Our goal is to assemble a group of
 vendors and operators (not "publish or perish" academics) to discuss and
 recommend effective strategies for incremental deployment of security
 solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
 is not to design new security protocols or to "write policy and
 procedures for operators" -- that would of course be over-reaching and
 presumptuous.  The goal is specifically to identify strategies for
 incremental deployment of the solutions designed and evaluated by the
 appropriate technical groups (e.g., IETF working groups).  And, while the
 SIGCOMM paper you mention is an example of such a strategy, it is just
 one single example -- and is by no means the recommendation of a group
 that is not yet even fully assembled yet.  The working group will debate
 and discuss a great many issues before suggesting any strategies, and
 those strategies would be the output of the entire working group.

  As for "publish or perish" academics, I doubt you'll
 find that the small set of academics who choose to go knee deep into
 operational issues do so because they are trying to optimize their
 academic careers... ;) 

 -- Jen

>>>
>>>
>>
>
>

Re: Do Not Complicate Routing Security with Voodoo Economics

[Jennifer Rexford]

Randy,

Yes, as the brief write-up says, the group will make "recommendations regarding 
the adoption" (e.g., suggesting effective strategies for incremental 
deployment) of "procedures and protocols based on existing work" (e.g., RPKI, 
BGP-SEC, etc.).  In any case, if our current wording is unclear, we can easily 
revise it to clarify our goals.

-- Jen


On Sep 4, 2011, at 1:56 PM, Randy Bush wrote:

>> As one of the co-chairs of this working group, I'd like to chime in to
>> clarify the purpose of this group.  Our goal is to assemble a group of
>> vendors and operators (not "publish or perish" academics) to discuss and
>> recommend effective strategies for incremental deployment of security
>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>> is not to design new security protocols or to "write policy and
>> procedures for operators"
> 
>This Working Group will recommend the framework for an industry
>agreement regarding the adoption of secure routing procedures and
>protocols based on existing work in industry and research. The
>framework will include specific technical procedures and protocols. The
>framework will be proposed in a way suitable for opt-in by large
>Internet Service Providers...
> 
> randy

Re: Do Not Complicate Routing Security with Voodoo Economics

[Jennifer Rexford]

Neil,

> maybe volunteers from the nanog community should contact you?

Thanks for the suggestion!  Yes, I would encourage interested people to contact 
me.  We won't be able to put everyone on the working group (in the interest of 
having a small enough group to make progress), but we are very interested in 
having people who can offer their expertise, feedback, and advice throughout 
the process...

-- Jen


> 
> On 4 Sep 2011, at 16:45, "Jennifer Rexford"  wrote:
> 
>> Neil,
>> 
>> The group is being assembled right now, so we don't have a list as of yet. 
>> 
>> -- Jen
>> 
>> 
>> Sent from my iPhone
>> 
>> On Sep 4, 2011, at 11:32 AM, "Neil J. McRae"  wrote:
>> 
>>> Jen,
>>> What operators are involved? And who represents them specifically?
>>> 
>>> Neil.
>>> 
>>> On 04/09/2011 16:07, "Jennifer Rexford"  wrote:
 
 
 As one of the co-chairs of this working group, I'd like to chime in to
 clarify the purpose of this group.  Our goal is to assemble a group of
 vendors and operators (not "publish or perish" academics) to discuss and
 recommend effective strategies for incremental deployment of security
 solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
 is not to design new security protocols or to "write policy and
 procedures for operators" -- that would of course be over-reaching and
 presumptuous.  The goal is specifically to identify strategies for
 incremental deployment of the solutions designed and evaluated by the
 appropriate technical groups (e.g., IETF working groups).  And, while the
 SIGCOMM paper you mention is an example of such a strategy, it is just
 one single example -- and is by no means the recommendation of a group
 that is not yet even fully assembled yet.  The working group will debate
 and discuss a great many issues before suggesting any strategies, and
 those strategies would be the output of the entire working group.
 
  As for "publish or perish" academics, I doubt you'll
 find that the small set of academics who choose to go knee deep into
 operational issues do so because they are trying to optimize their
 academic careers... ;) 
 
 -- Jen
 
>>> 
>>> 
>> 
> 

Re: Do Not Complicate Routing Security with Voodoo Economics

[jim deleskie]

Because routing to peers as a policy instead of customer as a matter
of policy, outside of corner cases make logical sence. While many
providers aren;t good at making money it is fact the purpose of the
ventures.  If I route to a customer I get paid for it.  If I send it
to a peer I do not.



On Sun, Sep 4, 2011 at 2:57 PM, Randy Bush  wrote:
>> While I can think of some corner cases for this, ie you have a
>> satellite down link from one provider and fiber to anther.  I expect
>> this is not the norm for most networks/customers.
>
> what is it you do not understand about "more than one of the world's
> largest providers?"  not in corner cases, but as core policy.
>
> randy
>

Re: Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

> Because routing to peers as a policy instead of customer as a matter
> of policy, outside of corner cases make logical sence.

welcome to the internet, it does not always make logical sense at first
glance.

the myth in academia that customers are always preferred over peers
comes from about '96 when vaf complained to asp and me (and we moved it
to nanog for general discussion) that we were not announcing an
identical prefix list to him at east and west.  the reason turned out to
be that, on one of the routers, a peer path was shorter in some cases,
so we had chosen it.  we were perfectly happy with that but vaf was not,
and he ran the larger network so won the discussion.

randy

Re: Do Not Complicate Routing Security with Voodoo Economics

[Sharon Goldberg]

In response to Randy's three criticisms of our recent
SIGCOMM'11/NANOG'52 paper, which is available here:

http://www.cs.bu.edu/~goldbe/papers/SBGPtrans_full.pdf
http://www.cs.toronto.edu/~phillipa/sbgpTrans.html

Point 1: "The ISP economic and incentive model is overly naive to the
point of being misleading"

To clarify, our paper focuses on the following question:

Given that we want as many ASes as possible to deploy path validation
(S*BGP), what sort of incremental deployment strategy should we use?

To answer this question, one first needs to understand why an AS might
have incentive to deploy S*BGP in the first place.  There are many
possible reasons (e.g., "the benefits of security" that Randy
mentions, pressure from regulators, governments, or other ASes, PR
opportunities, etc), in this paper we focused on one very specific
incentive:

An ISP might deploy S*BGP in order to increase the volume of traffic
that it transits for its customers.

We use this incentive as an "economic lever" that can be used to drive
global S*BGP deployment.   The paper shows that, even disregarding
other economic levers (like security concerns, regulations, PR, etc),
this incentive is enough to cause the majority of the Internet to
deploy S*BGP, even if (a) security plays a very small role in the BGP
decision process (i.e. security considerations influence routing
decisions only _after_ Local-Pref and AS-PATH considerations), and
even if (b) only a very small number (about 10) of ASes are "early
adopters" that initially deploy S*BGP.

Other economic levers (e.g. "the benefits of security") are
complementary, and can only aid in driving S*BGP deployment.

Our model assumes that ISPs have incentives to increase the volume of
customer traffic that they transit because "the dominant form of
pricing" in the Internet is based on traffic volumes sent, that is
95/5 percentile pricing:

http://drpeering.net/AskDrPeering/blog/articles/Ask_DrPeering/Entries/2011/4/29_The_Origins_of_95_5.html

Thus, the more traffic (at the 95 percentile) that an ISP transits for
its customer, the more they can charge that customer, and thus the
more revenue they earn.

Of course, this is not the case for *every* ISP: some ISPs may not use
95/5 percentile pricing at all, some ISPs may actually be losing money
by providing Internet transit, and are instead earning all their
revenue from other sources (e.g. IPTV, VPN, advertising, etc.), and
moreover, content providers and residential ISPs are connecting
directly more often, thus circumventing the charges of provider ISPs.
 However, major ISPs are still needed to reach most destinations, and
smaller ISPs have a choice between multiple providers:

http://www.peeringdb.com/
http://valas.gtnoise.net/lib/exe/fetch.php?media=comm083-valancius.pdf

The fact that transit service prices are plummeting is, amongst other
things, evidence of the fierce competition between ISPs over customer
traffic.  The key point of our incremental deployment strategy is to
give ISPs one more dimension along which they can compete; namely, the
ability to provide secure routes to their customers. This point is
still valid as long as _most_ ISPs earn _some_ of their revenue from
transiting customer traffic.  The existence of services like Guavus,
suggest that for many ISPs, this is indeed the case:

http://www.guavus.com/solutions/tiered-pricing

Point 2: "The security threat model is unrealistic and misguided"

Our paper does not present a security threat model at all. We do not
present a new security solution. We do not deal with the question of
whether or not S*BGP should be deployed at all, which specific
protocol (e.g. SBGP,soBGP, etc) should be deployed, or which security
guarantees should be provided. This is the subject of many previous
works. From Section 2.1: "Because our study is indifferent to attacks
and adversaries, it applies equally to each of these protocols [i.e.
SBGP, soBGP]."

As explained above, we focus only on the question "Given that we want
as many ASes as possible to adopt S*BGP, what sort of incremental
deployment strategy should we use?" Thus, we are simply trying to
maximize the number of ASes that deploy S*BGP.

Point 3: "The simulations are questionable."

>From Section 8: "The wide range of parameters involved in modeling
S*BGP deployment means that our model cannot be predictive of S*BGP
deployment in practice. Instead, our model was designed to (a) capture
a few of the most crucial issues that might drive S*BGP deployment,
while (b) taking the approach that simplicity is preferable to
complexity."

Because ASes are unwilling to divulge information about routing
policies, peering agreements, etc, every study of interdomain routing
must contend with a dearth of ground truth with respect to AS-level
topology, routing policies, and traffic matrices.  We preformed
extensive simulations to deal with this lack of ground truth. Please
see Section 8 of our paper for detailed discussion about these issues.

Re: Do Not Complicate Routing Security with Voodoo Economics

[Valdis . Kletnieks]

On Sun, 04 Sep 2011 16:16:45 EDT, Sharon Goldberg said:

> Point 2: "The security threat model is unrealistic and misguided"
> 
> Our paper does not present a security threat model at all. We do not
> present a new security solution.

Unfortunately for all concerned, it's going to be *perceived* as a security
solution, and people will invent a threat model to match.  Anybody who thinks
otherwise is invited to compare what people *think* the meaning of the little
padlock their browser displays versus what the padlock *actually* means, or the
difference between what people *think* SPF does for their email versus what it
*actually* does.




pgpmB854ZjV5a.pgp
Description: PGP signature

Re: Do Not Complicate Routing Security with Voodoo Economics

[Neil J. McRae]

On 4 Sep 2011, at 21:17, "Sharon Goldberg"   wrote:

thanks for responding you paper is interesting,

> Thus, while we cannot hope to accurately model every aspect of
> interdomain routing, nor predict how S*BGP deployment will proceed in
> practice, we believe that ISP competition over customer traffic is a
> significant economic lever for driving global S*BGP deployment.

 If you cannot accurately model every aspect of interdomain routing - why is 
that? :)

Then how can you be sure that a single stock in this model can be so 
influential? "significant" I think one could almost argue the opposite also or 
make the same case about nearly any feature in a transit product! If i stop 
offering community based filtering- I'd probably see revenue decline!

Yes some features in a product set drive revenue - thats all you are really 
saying which is fine but we have alot of features people want in the network 
and what would be a more useful paper would be why this one might drive more 
revenue growth than the others that are all fighting development prioritisation 
- - - which isnt clear to me in your paper.

All this paper does is confuse (mislead?) people that SBGP might have a big pot 
of gold attached which is doubtful in my view (interdomain routing is very 
complex) and the point Randy made.

Neil

Re: Do Not Complicate Routing Security with Voodoo Economics

[Michael Schapira]

On Sun, Sep 4, 2011 at 5:39 PM Neil J. McRae n...@domino.org wrote:

> ... one could almost argue the opposite also or make the same case about 
> nearly any feature in a transit product! If i stop offering
> community based filtering- I'd probably see revenue decline!
 
> Yes some features in a product set drive revenue - thats all you are really 
> saying which is fine but we have alot of features people want in
> the network and what would be a more useful paper would be why this one might 
> drive more revenue growth than the others that are all fighting
> development prioritisation - - - which isnt clear to me in your paper."



One crucial way in which S*BGP differs from other features is that ASes which 
deploy S*BGP *must* use their ability to validate paths to inform route 
selection (otherwise, adding security to BGP makes no sense). Therefore, S*BGP 
is bound to affect how traffic flows on the Internet. Our work is about 
harnessing this observation to drive S*BGP deployment.
 
We consider the case that security plays a very small role in the BGP decision 
process and, in particular, that security considerations come *after* the 
Local-Pref and AS-PATH length steps in the BGP decision process. We give 
evidence that even in this case a small set of early adopters is sufficient to 
transition a large fraction of the Internet to S*BGP.
 
 

 

Re: Do Not Complicate Routing Security with Voodoo Economics

[Dobbins, Roland]

On Sep 5, 2011, at 11:04 AM, Michael Schapira wrote:

> One crucial way in which S*BGP differs from other features is that ASes which 
> deploy S*BGP *must* use their ability to validate paths to inform route 
> selection (otherwise, adding security to BGP makes no sense).

Origin validation <> path validation.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Do Not Complicate Routing Security with Voodoo Economics

[Dobbins, Roland]

On Sep 5, 2011, at 11:55 AM, Dobbins, Roland wrote:

> Origin validation <> path validation.

Rather, that should read, 'Origin/path validation <> origin/path enforcement'.

The idea of origin validation is a simple one.  The idea of path validation 
isn't to determine the 'correctness' or 'desirability' of a particular AS-path, 
but rather to determine the *validity* (or at least the *feasability*) of a 
given AS-path.  

Origin validation is relatively easy compared to AS-path validation, and origin 
validation is the most important function of S*BGP.  And in a world with 
universal origin and AS-path validation, how is there some economic advantage 
to be had by deploying S*BGP?  

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

> One crucial way in which S*BGP differs from other features is that
> ASes which deploy S*BGP *must* use their ability to validate paths to
> inform route selection

not really.  you may wish to read the bgpsec docs, in particular
draft-ietf-sidr-bgpsec-ops

randy

Re: Do Not Complicate Routing Security with Voodoo Economics

[Aftab Siddiqui]

Hi Jen,


> Thanks for the suggestion!  Yes, I would encourage interested people to
> contact me.  We won't be able to put everyone on the working group (in the
> interest of having a small enough group to make progress), but we are very
> interested in having people who can offer their expertise, feedback, and
> advice throughout the process...
>
> Well, Why not everyone? What would be the criteria to add people into the
working group? IETF or any RIR doesn't stop anyone from joining any WG.
Every member of the WG should be treated as potential contributor.


Regards,

Aftab A. Siddiqui.

Re: Do Not Complicate Routing Security with Voodoo Economics

[Leo Bicknell]

In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon Goldberg 
wrote:
> An ISP might deploy S*BGP in order to increase the volume of traffic
> that it transits for its customers.

I think this phrase summarizes the problem with this argument nicely.

If, as an ISP, deploying a "secure" routing protocol changes my
traffic positively or negatively something is wrong.  Securing the
routing system should not alter the routing system.

I'm afraid as long as it does this work has an uphill battle.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpl2huz3upMg.pgp
Description: PGP signature

Re: Do Not Complicate Routing Security with Voodoo Economics

[Owen DeLong]

On Sep 5, 2011, at 5:47 AM, Leo Bicknell wrote:

> In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon 
> Goldberg wrote:
>> An ISP might deploy S*BGP in order to increase the volume of traffic
>> that it transits for its customers.
> 
> I think this phrase summarizes the problem with this argument nicely.
> 
> If, as an ISP, deploying a "secure" routing protocol changes my
> traffic positively or negatively something is wrong.  Securing the
> routing system should not alter the routing system.
> 
> I'm afraid as long as it does this work has an uphill battle.
> 

One could argue that rejecting routes which you previously had no way to
know you should reject will inherently alter the routing system and that this
is probably a good thing.

Owen

Re: Do Not Complicate Routing Security with Voodoo Economics

[Jennifer Rexford]

> 
> One could argue that rejecting routes which you previously had no way to
> know you should reject will inherently alter the routing system and that this
> is probably a good thing.

Good point.  Also, "tie breaking" in favor of signed-and-verified routes over 
not-signed-and-verified routes does not necessarily affect your traffic 
"positively or negatively" -- rather, if you are letting an arbitrary final tie 
break make the decision anyway, you are arguably *neutral* about the outcome...

-- Jen

RE: Do Not Complicate Routing Security with Voodoo Economics

[Michael Schapira]

On Sep 5, 2011, at 11:55 AM, Dobbins, Roland wrote:

> The idea of origin validation is a simple one.  The idea of path validation 
> isn't to determine the 'correctness' or 'desirability' of a
> particular AS-path, but rather to determine the *validity* (or at least the 
> *feasability*) of a given AS-path.


Sorry, I was misunderstood. To clarify, I was referring only to our work 
(http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html), where security does play 
a small role in the route selection process (after LocalPref and AS-PATH 
length), and not to the BGPsec spec. The reason why we assume that security 
affects the route selection process is because otherwise, even an AS that 
deploys S*BGP, remains vulnerable to attacks. To see why, take a look at slides 
10-13 of our NANOG presentation 
(http://www.cs.bu.edu/~goldbe/papers/Goldberg-TransitionToSBGP-NANOG.pdf, video 
available at http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html). The basic 
idea is: if an AS prefers short paths over secure paths they'll be just as 
vulnerable to path-shortening attacks with and without S*BGP.

Re: Do Not Complicate Routing Security with Voodoo Economics

[Owen DeLong]

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 that this
>> is probably a good thing.
> 
> Good point.  Also, "tie breaking" in favor of signed-and-verified routes over 
> not-signed-and-verified routes does not necessarily affect your traffic 
> "positively or negatively" -- rather, if you are letting an arbitrary final 
> tie break make the decision anyway, you are arguably *neutral* about the 
> outcome...
> 
> -- Jen

This is true in terms of whether you care or not, but, if one just looks at 
whether it changes the content of the FIB or not, changing which arbitrary 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 database such 
as the routing table, you will inherently be changing the contents of said 
database, or, your security isn't actually accomplishing anything.

Owen

Re: Do Not Complicate Routing Security with Voodoo Economics

[Joe Maimon]

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 that this
is probably a good thing.


Good point.  Also, "tie breaking" in favor of signed-and-verified routes over 
not-signed-and-verified routes does not necessarily affect your traffic "positively or 
negatively" -- rather, if you are letting an arbitrary final tie break make the decision 
anyway, you are arguably *neutral* about the outcome...

-- Jen


This is true in terms of whether you care or not, but, if one just looks at 
whether it changes the content of the FIB or not, changing which arbitrary 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 database 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 
about 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 adopting secured BGP. We might be lucky there too.


Perhaps this will finally help solve the routing slot scalability 
problem. Might also jumpstart LISP. Which may put some more steam into 
v6. Welcome to the brave new internet.


Good for everyone, right?

Are you feeling lucky?


Joe

Re: Do Not Complicate Routing Security with Voodoo Economics

[Nick Feamster]

Three thoughts on the thread so far.

1. I think Randy raises an interesting point about the complexity of contracts. 
 We had a paper in SIGCOMM this year on the increasing use of more complicated 
interconnection contracts (and, in particular, tiered pricing).  See Section 2 
of our paper [1]:
http://www.gtnoise.net/papers/library/valancius-tiers.pdf
Some of us academics are trying to get more clued up on what providers actually 
do. :-)  [I may start a discussion on the pricing models in this paper in a 
separate thread later]

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

3. I think the discussion on the list so far misses what I see as the central 
question about the economic assumptions in that paper.  The paper assumes that 
all destinations are equally valuable, which we know is not the case.  This 
implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 
ISPs, whereas in practice, it may be with other ASes (e.g., Google).  In 
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).  If the most "valuable" destinations deployed S-BGP 
and made everyone who wanted to connect to them deploy it, that would be more 
likely to succeed than the approach taken in the paper, I think.

Conclusion: All of these questions above make me wonder about two more general 
assumptions that it would be good to get some more insight into:
* Who "holds the cards", in terms of dictating the terms of 
interconnection?  Content providers?  Access networks/eyeballs?  Tier-1s?  
(many of the recent peering spats recently seem to indicate that various ASes 
are trying to shake the current balance(s) of power, it seems)
* How complicated are interconnection contracts today, and how have 
they evolved? (i.e., how common is a random tiebreak, and how does that differ 
by network?)

-Nick

-

[1] Valancius, V. and Lumezanu, C. and Feamster, N. and Johari, R. and 
Vazirani, V.V.
How Many Tiers? Pricing in the Internet Transit Market
In ACM SIGCOMM, 2011


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 that 
 this
 is probably a good thing.
>>> 
>>> Good point.  Also, "tie breaking" in favor of signed-and-verified routes 
>>> over not-signed-and-verified routes does not necessarily affect your 
>>> traffic "positively or negatively" -- rather, if you are letting an 
>>> arbitrary final tie break make the decision anyway, you are arguably 
>>> *neutral* about the outcome...
>>> 
>>> -- Jen
>> 
>> This is true in terms of whether you care or not, but, if one just looks at 
>> whether it changes the content of the FIB or not, changing which arbitrary 
>> 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 database 
>> 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 about 
> 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 
> adopting secured BGP. We might be lucky there too.
> 
> Perhaps this will finally help solve the routing slot scalability problem. 
> Might also jumpstart LISP. Which may put some more steam into v6. Welcome to 
> the brave new internet.
> 
> Good for everyone, right?
> 
> Are you feeling lucky?
> 
> 
> Joe
> 

Re: Do Not Complicate Routing Security with Voodoo Economics

[Dobbins, Roland]

On Sep 5, 2011, at 11:51 PM, Nick Feamster wrote:

>  If the most "valuable" destinations

'Most valuable', 'least expensive', 'least congested', 'most reliable', 'most 
responsive', 'least contractually onerous', 'most generous ratio', 'most  
lucrative', et. al. - all these criteria and more come into play in the context 
of traffic engineering, and they're all relative to who you are and where you 
are and where you want your traffic/their traffic/someone else's traffic to go. 
 

And all the above vary depending upon your business type, business model, 
geographical reach, topological diversity, etc.  So, as you imply, one set of 
economic parameters and weights for one SP will be completely different for the 
economic parameters and weights for another SP.  It's possible to roughly 
generalize based upon SP type, but there are many, many variables which will 
affect routing selection complexity.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Do Not Complicate Routing Security with Voodoo Economics

[Owen DeLong]

On Sep 5, 2011, at 8: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 that 
 this
 is probably a good thing.
>>> 
>>> Good point.  Also, "tie breaking" in favor of signed-and-verified routes 
>>> over not-signed-and-verified routes does not necessarily affect your 
>>> traffic "positively or negatively" -- rather, if you are letting an 
>>> arbitrary final tie break make the decision anyway, you are arguably 
>>> *neutral* about the outcome...
>>> 
>>> -- Jen
>> 
>> This is true in terms of whether you care or not, but, if one just looks at 
>> whether it changes the content of the FIB or not, changing which arbitrary 
>> 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 database 
>> 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 about 
> the future where we may be less lucky.
> 

I'm pretty sure that there is actually a fair amount of pollution in the 
routing table today and that it will only get worse until we have some form of 
security.

I believe that most spammers operate by advertising hijacked prefixes for short 
periods of time and then going away before people can react.

Since there have been multiple instances of proof of my above belief, I would 
find it very hard to believe we have been lucky until now.

> What I would be interested in seeing is a discussion on whether any 
> anti-competitive market distortion incentives exist for large providers in 
> adopting secured BGP. We might be lucky there too.
> 

Of course they do. We probably won't get particularly lucky there, either.

> Perhaps this will finally help solve the routing slot scalability problem. 
> Might also jumpstart LISP. Which may put some more steam into v6. Welcome to 
> the brave new internet.
> 

Probably not. I really doubt it will do much to help LISP.

Contrary to many people's opinions, I think that IPv4 address shortage and the 
coming costs of attempting to maintain IPv4 on life support will put more steam 
into IPv6 than any artificial move we could make in this area.

> Good for everyone, right?
> 

IPv6 is good for everyone whether they realize it or not.

LISP I'm not as convinced.

> Are you feeling lucky?
> 

No, not really.

Owen

Re: Do Not Complicate Routing Security with Voodoo Economics

[Sharon Goldberg]

Nick Feamster wrote:
> 2. I question what fraction of routing decisions come down to a blind 
> tiebreak---nearly all of them are likely to be driven by some other 
> consideration (reliability, cost, etc.).  Our paper details a richer economic 
> model by which ASes actually select paths, for example, but it's still 
> unclear to me how coarse or fine-grained route selection really is in 
> practice, and to what extent more complicated contracts have evolved.  I 
> wonder how common "blind tiebreaking" is in BGP, in real networks; the 
> approach in Sharon's paper definitely may overstate how common that is if 
> route selection considerations commonly involve things that are not visible 
> in the AS graph (e.g., traffic ratios, congestion, performance), but 
> academics could really benefit 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 central 
> question about the economic assumptions in that paper.  The paper assumes 
> that all destinations are equally valuable, which we know is not the case.  
> This implicitly (and perhaps mistakenly?) shifts the balance of power to 
> tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google).  
> In 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).  If the most "valuable" destinations deployed 
> S-BGP and made everyone who wanted to connect to them deploy it, that would 
> be more likely to succeed than the approach taken in the paper, 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 results 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 that 
> this
> is probably a good thing.

 Good point.  Also, "tie breaking" in favor of signed-and-verified routes 
 over not-signed-and-verified routes does not necessarily affect your 
 traffic "positively or negatively" -- rather, if you are letting an 
 arbitrary final tie break make the decision anyway, you are arguably 
 *neutral* about the outcome...

 -- Jen
>>>
>>> This is true in terms of whether you care or not, but, if one just looks at 
>>> whether it changes the content of the FIB or not, changing which arbitrary 
>>> 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 database 
>>> such as the routing table, you will inherently be changing the contents of 
>>> said database, or, your security isn't actually accomplishing anything.
>>>
>>> O

Re: Do Not Complicate Routing Security with Voodoo Economics

[Owen DeLong]

> 
>> 3. I think the discussion on the list so far misses what I see as the 
>> central question about the economic assumptions in that paper.  The paper 
>> assumes that all destinations are equally valuable, which we know is not the 
>> case.  This implicitly (and perhaps mistakenly?) shifts the balance of power 
>> to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., 
>> Google).  In 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).  If the most "valuable" destinations 
>> deployed S-BGP and made everyone who wanted to connect to them deploy it, 
>> that would be more likely to succeed than the approach taken in the paper, 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).
> 

The point here, however, is that the value is subjective. Not all content 
providers
are equally valuable. An access provider will get many complaints from users
if they are unable to reach some content providers (e.g. google) while they will
get relatively few complaints if they are unable to access others
(e.g. hasthelargehadroncolliderdestroyedtheworldyet.com).

Owen

Re: Do Not Complicate Routing Security with Voodoo Economics

[Alexander Harrowell]

On Monday 05 Sep 2011 15:53:38 Owen DeLong wrote:
> This is true in terms of whether you care or not, but, if one just 
looks at whether it changes the content of the FIB or not, changing 
which arbitrary 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 
database such as the routing table, you will inherently be changing the 
contents of said database, or, your security isn't actually 
accomplishing anything.

This is true and should probably be considered a universal law. If the 
introduction of security precautions to a system does not change the 
system, the security precautions are ineffective. 

This is based on the principle that people and systems are imperfect, so 
it is extremely unlikely that there are no bad actors or wildlife in the 
pre-security state, and further that false-positive results are 
inevitable. It has the corollary that introducing security precautions 
is invariably costly, and therefore that you must consider the security 
gain relative to the inevitable costs before deciding to do so.

This is of course an intellectually difficult problem. With regard to 
BGP, the security gain is not so much determined by how bad the problem 
is now, as by how bad it could potentially be if someone took it into 
their heads to tear up the rules and declare war. The answer is "very, 
very bad indeed" which is why we're having this discussion.

It also reminds me of J.K. Galbraith's notion of the bezzle - at any 
time, there is an inventory of undiscovered embezzlement in the economy. 
Before it is discovered, both the fraudster and his or her victim 
believe themselves to possess the money that has been stolen - there is 
a net increase in psychic wealth, in JKG's words. In times of 
prosperity, the bezzle grows, and in times of recession, it shrinks.

There is a bezzle of indeterminate size in the routing table, but we 
won't find out how big it is until we audit it (i.e. deploy SBGP). Some 
of it will just be randomness - misconfigurations and errors - but some 
of it will be enemy action.


-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them


signature.asc
Description: This is a digitally signed message part.