Re: anyone from netnames / ascio on list?

[Andrew Mulholland]

It was resolved last night.

http://www.guardian.co.uk/technology/2011/sep/05/dns-hackers-telegraph-interview

Andrew



On Mon, Sep 5, 2011 at 7:15 AM, Andrew Kirch  wrote:

> On 9/4/2011 5:34 PM, Andrew Mulholland wrote:
>
> I'm not seeing the problem here?
> Registrant:
>  Gateway, Inc. (GATEW95532)
>  7565 Irvine Center Drive
>
>  Irvine, CA, 92618-2930
>  US
>
>  Domain name: acer.com
>
> Technical contact:
>  Administrator, Domain (DA73355)
>  NetNames Hostmaster
>  3rd Floor Prospero House
>  241 Borough High Street
>  Borough, London, SE1 1GA
>  GB
>  corporate-servi...@netnames.com
>  +44.2070159370 Fax: +44.2070159375
>
> Administrative contact:
>  Wagner, Michael (MW47730)
>  Gateway, Inc.
>  7565 Irvine Center Drive
>
>  Irvine, CA, 92618-2930
>  US
>  hostad...@gateway.com
>  +1.8008462042 Fax: +1.00
>
> Record created:   2010-10-04 17:54:28
> Record last updated:  2011-09-04 22:24:04
> Record expires:   2019-05-17 01:00:00
>
> Domain servers in listed order:
>  ns1.acer.com (NS1ACERC38319)
>  ns2.acer.com (NS2ACERC59089)
>  ns3.acer.com (NS3ACERC70649)
>  ns4.acer.com (NS4ACERC28541)
>  ns5.acer.com (NS5ACERC49101)
>  ns6.acer.com (NS6ACERC86343)
>
>
>

Re: anyone from netnames / ascio on list?

[Andrew Kirch]

On 9/4/2011 5:34 PM, Andrew Mulholland wrote:

I'm not seeing the problem here?
Registrant:
  Gateway, Inc. (GATEW95532)
  7565 Irvine Center Drive

  Irvine, CA, 92618-2930
  US

  Domain name: acer.com

Technical contact:
  Administrator, Domain (DA73355)
  NetNames Hostmaster
  3rd Floor Prospero House
  241 Borough High Street
  Borough, London, SE1 1GA
  GB
  corporate-servi...@netnames.com
  +44.2070159370 Fax: +44.2070159375

Administrative contact:
  Wagner, Michael (MW47730)
  Gateway, Inc.
  7565 Irvine Center Drive

  Irvine, CA, 92618-2930
  US
  hostad...@gateway.com
  +1.8008462042 Fax: +1.00

Record created:   2010-10-04 17:54:28
Record last updated:  2011-09-04 22:24:04
Record expires:   2019-05-17 01:00:00

Domain servers in listed order:
  ns1.acer.com (NS1ACERC38319)
  ns2.acer.com (NS2ACERC59089)
  ns3.acer.com (NS3ACERC70649)
  ns4.acer.com (NS4ACERC28541)
  ns5.acer.com (NS5ACERC49101)
  ns6.acer.com (NS6ACERC86343)

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

[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

[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: Preferring peers over customers [was: Do Not Complicate Routing

[Avi Freedman]

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  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, wi

Preferring peers over customers [was: Do Not Complicate Routing Security with Voodoo Economics]

[Patrick W. Gilmore]

On Sep 5, 2011, at 4:03, Randy Bush  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: iCloud - Is it going to hurt access providers?

[Jeff Wheeler]

On Sun, Sep 4, 2011 at 4:45 PM, Wayne E Bouchard  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 
Sr Network Operator  /  Innovative Network Concepts

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

anyone from netnames / ascio on list?

[Andrew Mulholland]

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

[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: iCloud - Is it going to hurt access providers?

[Wayne E Bouchard]

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: Tampa small colo recs?

[Blake T. Pfankuch]

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

[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

[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

[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

[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

[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

[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

[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

[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: Tampa small colo recs?

[James P. Ashton]

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

[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]

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]

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

[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

[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

[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

[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

[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

[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

[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

[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: iCloud - Is it going to hurt access providers?

[Valdis . Kletnieks]

On Sat, 03 Sep 2011 18:38:40 EDT, Jay Ashworth said:

> Two people making the same mistake: end-user support telephone calls don't 
> generally go to datacenters, do they? 

Maybe they've figured out how to let an AI answer the phones. All you need is
text-to-speech, speech-to-text, and the script the outsourced semi-trained
monkeys would have been using.

Or maybe they've not been outsourced at all, and 'Mumbai' is the codeword for
the data center, and it's all a coverup because even outsourcing a job is an
easier PR job than replacing somebody with a robot/computer. ;)



pgpqSb0bkrdVc.pgp
Description: PGP signature

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

[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: iCloud - Is it going to hurt access providers?

[Florian Weimer]

* 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.

Do Not Complicate Routing Security with Voodoo Economics

[Randy Bush]

[ 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