Do Not Complicate Routing Security with Voodoo Economics
[ 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 ra...@psg.com 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: iCloud - Is it going to hurt access providers?
* Wayne E. Bouchard: the users will screw themselves by flooding their uplinks in which case they will know what they've done to themselves and will largely accept the problems for the durration With shared media networks (or insufficient backhaul capacities), congestion affects more than just the customer causing it.
Re: Do Not Complicate Routing Security with Voodoo Economics
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 rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Do Not Complicate Routing Security with Voodoo Economics
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 ra...@psg.com 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 ra...@psg.com 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
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
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
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 ra...@psg.com 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
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 patr...@ianai.net Date: Sun, 4 Sep 2011 09:51:12 To: North American Network Operators' Groupnanog@nanog.org 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 ra...@psg.com 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
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
-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
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
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 ra...@psg.com 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
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. tongue in cheek 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... ;) /tongue in cheek -- Jen
Re: Do Not Complicate Routing Security with Voodoo Economics
Jen, What operators are involved? And who represents them specifically? Neil. On 04/09/2011 16:07, Jennifer Rexford j...@cs.princeton.edu 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. tongue in cheek 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... ;) /tongue in cheek -- Jen
Re: Tampa small colo recs?
Jay, I recommend E Solutions, But I am biased (I build the network). But also in town we have, Switch and Data Qwest Peak 10 Sago Networks Hostway I know them all pretty well, so if you have any questions, fire away. James - Original Message - Anyone got any opinions on small colo rental in Tampa; anywhere from 8RU to a half-rack? I'd prefer at least one tier 1 uplink, and at least 1 tier 2, dial-a-yield 100Base, and 24 hour access, but I'm flexible. Pinellas County is also fine. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Do Not Complicate Routing Security with Voodoo Economics
maybe volunteers from the nanog community should contact you? On 4 Sep 2011, at 16:45, Jennifer Rexford j...@cs.princeton.edu 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 n...@domino.org wrote: Jen, What operators are involved? And who represents them specifically? Neil. On 04/09/2011 16:07, Jennifer Rexford j...@cs.princeton.edu 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. tongue in cheek 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... ;) /tongue in cheek -- Jen
Re: Do Not Complicate Routing Security with Voodoo Economics
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
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
+1 -Tk On Sep 4, 2011, at 12:23 PM, Neil J. McRae n...@domino.org wrote: maybe volunteers from the nanog community should contact you? On 4 Sep 2011, at 16:45, Jennifer Rexford j...@cs.princeton.edu 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 n...@domino.org wrote: Jen, What operators are involved? And who represents them specifically? Neil. On 04/09/2011 16:07, Jennifer Rexford j...@cs.princeton.edu 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. tongue in cheek 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... ;) /tongue in cheek -- Jen
Re: Do Not Complicate Routing Security with Voodoo Economics
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 j...@cs.princeton.edu 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 n...@domino.org wrote: Jen, What operators are involved? And who represents them specifically? Neil. On 04/09/2011 16:07, Jennifer Rexford j...@cs.princeton.edu 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. tongue in cheek 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... ;) /tongue in cheek -- Jen
Re: Do Not Complicate Routing Security with Voodoo Economics
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 ra...@psg.com 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
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
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. Here I'll address
RE: Tampa small colo recs?
I've managed a few servers from sago, they have a great network and quick support responses as needed. Hostway not had quite as good of responses from them, and some weird network issues. However that was a few years back. -Original Message- From: James P. Ashton [mailto:ja...@gitflorida.com] Sent: Sunday, September 04, 2011 11:31 AM To: Jay Ashworth Cc: NANOG Subject: Re: Tampa small colo recs? Jay, I recommend E Solutions, But I am biased (I build the network). But also in town we have, Switch and Data Qwest Peak 10 Sago Networks Hostway I know them all pretty well, so if you have any questions, fire away. James - Original Message - Anyone got any opinions on small colo rental in Tampa; anywhere from 8RU to a half-rack? I'd prefer at least one tier 1 uplink, and at least 1 tier 2, dial-a-yield 100Base, and 24 hour access, but I'm flexible. Pinellas County is also fine. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: iCloud - Is it going to hurt access providers?
On Sun, Sep 04, 2011 at 12:56:25PM +0200, Florian Weimer wrote: * Wayne E. Bouchard: the users will screw themselves by flooding their uplinks in which case they will know what they've done to themselves and will largely accept the problems for the durration With shared media networks (or insufficient backhaul capacities), congestion affects more than just the customer causing it. Okay, so to state the obvious for those who missed the point... The congestion will either be directly in front of user because they're flooding their uplink or towards the destination (beit a single central network or a set of storage clusters housed at, say, 6 different locations off 3 different providers.) It is very hard, in my experience, for something like this to congest the general network. The congestion occurs where either bandwidth drops off--such as with the edge dialup, DSL, or cable modem link--or traffic concentrates. Just like someone broadcasting a concert. Either you as a user can't receive the feed because your pipe isn't big enough for the stream or the network/servers sourcing the traffic get bogged down and, generally, the rest of the folks out there not watching the feed don't know there's a problem. If you're not participating in that traffic, the likelihood that you'll be impacted by it drops off dramatically. Yes, the PTP model will behave a little differently but in that case, you're more likely to see individual users having issues (either hosts or clients) rather than everyone as a whole and it *still* won't impact the broader network. The more central clusters you add, the more the traffic pattern will start to behave like the PTP scenario and the lower the probabilty of broad impact. My point was simply that if you think it through, there really isn't any reason to be concerned about it. (It can't be any worse than the Jackson verdict or the Pope and, as far as I recall, since we're all still here, I don't believe the world ended when those events happened.) -Wayne --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/
Re: Do Not Complicate Routing Security with Voodoo Economics
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
anyone from netnames / ascio on list?
Hi Seems Netnames / Ascio have been compromised, resulting in DNS servers for a number of their customers (telegraph.co.uk, acer.com, betfair.com , theregister.co.uk etc) being changed, and the sites being redirected to an hacked page. list of domains affected here: http://zone-h.org/archive/notifier=turkguvenligi.info Seems there's no 24/7 contact for them.. e.g. Domain Name: ACER.COM Registrar: ASCIO TECHNOLOGIES, INC. Whois Server: whois.ascio.com Referral URL: http://www.ascio.com Name Server: NS1.YUMURTAKABUGU.COM Name Server: NS2.YUMURTAKABUGU.COM Status: ok Updated Date: 04-sep-2011 Creation Date: 07-sep-1994 Expiration Date: 17-may-2019 If anyone on list works for them, please raise the alarm internally, and/or start responding to your customers! thanks Andrew
Re: Do Not Complicate Routing Security with Voodoo Economics
On 4 Sep 2011, at 21:17, Sharon Goldberg gol...@cs.bu.edu 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: iCloud - Is it going to hurt access providers?
On Sun, Sep 4, 2011 at 4:45 PM, Wayne E Bouchard w...@typo.org wrote: Okay, so to state the obvious for those who missed the point... The congestion will either be directly in front of user because they're flooding their uplink or towards the destination (beit a single central network or a set of storage clusters housed at, say, 6 different locations off 3 different providers.) It is very hard, in my If scaling up Internet bandwidth were the hardest thing about deploying SaaS / cloud services, don't you think transit vendors would suddenly be more profitable than EMC and friends? It should be obvious to you, and everyone else, that datacenter Internet connectivity is a trivial concern compared to everything else that goes into these platforms. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Preferring peers over customers [was: Do Not Complicate Routing Security with Voodoo Economics]
On Sep 5, 2011, at 4:03, Randy Bush ra...@psg.com wrote: 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. The myth comes from engineers at large networks saying it is so. We could also have a small miscommunication here. For example, if a customer were multi-homed to a peer, and the customer and peer were on the same router, and the customer had prepended a single time (making the AS path equal), by your original statement you would have sent traffic to the peer. Most people would find that silly. (And please do not point out customers and peers do not connect to the same router, this is a simple example for illustrative purposes.) However, the statement you make above says that you preferred the peer because the path was shorter. You do not specify if that is IGP distance, AS path length, or some other metric, but it implies if the path were equal, you would prefer the customer - especially since the customer was preferred on the other coast. So there may be assumptions on one side or the other that are not clear which are causing confusion. Either way, this seems operationally relevant. I would like the large networks of the world to state whether they prefer their customer routes over peer routes, and how. For instance, does $NETWORK prefer customers only when the AS path is the same, or all the time no matter what? Let's leave out corner cases - e.g. If a customer asks you, via communities or otherwise, to do something different. This is a poll of default, vanilla configurations. Please send them to me, or the list, with this subject line. I shall compile the results and post them somewhere public. If you cannot speak for your company, I will keep your name private. Thanx. -- TTFN patrick
Re: Preferring peers over customers [was: Do Not Complicate Routing
Forgive my potential lack of understanding; perhaps BGP behavior has changed or the way people use it has but my understanding is - Since BGP is used in almost all circumstances in a mode where only the best path to a prefix can be re-advertised, only one of the peer or customer path can be used by a 3rd network, and if the peer path is used for a prefix for a customer, then a transit provider can't easily provide transit for that prefix back to the customer without serious routing shennanigans. So isn't it in practice the case that if a provider prefers a peer to connect to a customer instead of the direct customer link, that: 1) The provider will lose the ability to bill for traffic delivered to that customer, and 2) The customer will lose redundancy of inbound path, and 3) The customer will almost certainly notice and have the chance to complain I would expect that most cases of a provider (for a given prefix, which is almost always a caveat here) preferring a peer to get to a customer would be something the customer had some input into via communities, or by calling and bitching if the provider doesn't have a rich communities set or the ability to set them. One thing one hears every so often (in cycles) is the pressure for emerging Tier1/2 aspirants to not peer with customers of larger potential peers who are also providers, to preserve revenue models of said larger peers, but that's a different situation. And - If applied to customers of customers, I'd think it'd revert to the cases above. Network X has customer Y and buys from provider C. If C prefers a peer to get to Y (this is all for a given prefix) and it wasn't due to policy expressed by X or Y via communities or request of provider C by X, then eventually someone's going to figure out that the backup path that presumably X and Y think is being paid for, isn't. Then the people that pay money will bitch and action shoudl be taken. Consistent announcements by a global network to its peers for the prefixes of a given customer is another level of wonkiness that customers can definitely influence by doing strange per-prefix communities settings, but that again is probably another topic as it'd be presumably driven by the customer's actions, not the provider's traffic-engineering goals. Or am I confused here on one, more, or all points? Certainly possible. One thing I think everyone can agree on - academic models of the ways that people combine routers, money, fiber, contracts, and policy almost never catch up to the creativity, poltiics, policy, bugs, and stupidities that combine to make the Internet as wonderful as it is. Avi On Sep 5, 2011, at 4:03, Randy Bush ra...@psg.com wrote: 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. The myth comes from engineers at large networks saying it is so. We could also have a small miscommunication here. For example, if a custome= r were multi-homed to a peer, and the customer and peer were on the same rou= ter, and the customer had prepended a single time (making the AS path equal)= , by your original statement you would have sent traffic to the peer. Most p= eople would find that silly. (And please do not point out customers and pee= rs do not connect to the same router, this is a simple example for illustrat= ive purposes.) However, the statement you make above says that you preferred the peer becau= se the path was shorter. You do not specify if that is IGP distance, AS p= ath length, or some other metric, but it implies if the path were equal, you= would prefer the customer - especially since the customer was preferred on t= he other coast. So there may be assumptions on one side or the other that a= re not clear which are causing confusion. Either way, this seems operationally relevant. I would like the large networks of the world to state whether they prefer th= eir customer routes over peer routes, and how. For instance, does $NETWORK p= refer customers only when the AS path is the same, or all the time no matter= what? Let's leave out corner cases - e.g. If a customer asks you, via communities o= r otherwise, to do something different. This is a poll of default, vanilla c= onfigurations. Please send them to me, or the list, with this subject line. I shall compil= e the
Re: Do Not Complicate Routing Security with Voodoo Economics
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
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 rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Do Not Complicate Routing Security with Voodoo Economics
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 rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
