- Test - lists.nanog.org

Tampa small colo recs?
by Jay Ashworth 05 Sep '11

05 Sep '11

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 jra(a)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

5 4

RE: Do Not Complicate Routing Security with Voodoo Economics
by Michael Schapira 05 Sep '11

05 Sep '11

On Sep 5, 2011, at 11:55 AM, Dobbins, Roland wrote: > The idea of origin validation is a simple one. The idea of path validation isn't to determine the 'correctness' or 'desirability' of a > particular AS-path, but rather to determine the *validity* (or at least the *feasability*) of a given AS-path. Sorry, I was misunderstood. To clarify, I was referring only to our work (http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html) where security does play a small role in the route selection process (after LocalPref and AS-PATH length), and not to the BGPsec spec. The reason why we assume that security affects the route selection process is because otherwise, even an AS that deploys S*BGP, remains vulnerable to attacks. To see why, take a look at slides 10-13 of our NANOG presentation (http://www.cs.bu.edu/~goldbe/papers/Goldberg-TransitionToSBGP-NANOG.pdf, video available at http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html) The basic idea is: if an AS prefers short paths over secure paths they'll be just as vulnerable to path-shortening attacks with and without S*BGP.

1 0

Re: Do Not Complicate Routing Security with Voodoo Economics
by Jennifer Rexford 05 Sep '11

05 Sep '11

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

5 8

Re: Do Not Complicate Routing Security with Voodoo Economics
by Michael Schapira 05 Sep '11

05 Sep '11

On Sun, Sep 4, 2011 at 5:39 PM Neil J. McRae neil(a)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.

3 3

anyone from netnames / ascio on list?
by Andrew Mulholland 05 Sep '11

05 Sep '11

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

2 2

Re: Preferring peers over customers [was: Do Not Complicate Routing
by freedman＠freedman.net 05 Sep '11

05 Sep '11

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 <randy(a)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 results and post them somewhere public. If you cannot speak for your c= > ompany, I will keep your name private. > > Thanx. > > -- > TTFN > patrick

1 0

ISP Two-Way Utilization Studies between Subscriber and Network
by Paul Donner 03 Sep '11

03 Sep '11

Can anyone point me to useful recent studies showing the ratio of downstream to upstream traffic loading for a typical home Internet user? Broken out by traffic type would be really nice but not holding my breath. Thanks, -Donner

2 1

Re: iCloud - Is it going to hurt access providers?
by Alex Rubenstein 03 Sep '11

03 Sep '11

I think is would be short term. The home user is not going to continuously upload data. They will do an initial sync, then incrementals. People are doing this today with success. This is not a new thing. Sent via Blackberry while presumably driving with one hand ----- Original Message ----- From: Skeeve Stevens <Skeeve(a)eintellego.net> To: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Sat Sep 03 07:20:13 2011 Subject: iCloud - Is it going to hurt access providers? Hey all, I've been thinking about the impact that iCloud (by Apple) will have on the Internet. My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres. Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox, but from an Access Providers perspective, I'm thinking this might be a 'bad thing'. From what I can see there are some key issues: * Users with plans that count upload and download together. * The speed of Asymmetric tail technology such as DSL * The design of access provider backhaul (from DSLAM to core) metrics * The design of some transit metrics So basically the potential issue is that a large residential provider could have thousands of users connect to iCloud, their connections slowed because of uploading data, burning their included bandwidth caps, slowing down the backhaul segment of the network, and as residential providers are mostly download, some purchase transit from their upstreams in an symmetric fashion. This post is really just to prompt discussion if people think there is anything to actually worry about, or there are other implications that I've not really thought of yet. …Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists skeeve(a)eintellego.net<mailto:skeeve@eintellego.net> ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego or eintellego(a)facebook.com<mailto:eintellego@facebook.com> twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade

4 3

serviceproviderworld.com
by Paul Stewart 03 Sep '11

03 Sep '11

Hey folks... I know a couple of folks behind this new site and thought it would be worthwhile for the NANOG community to be made aware of it. http://www.serviceproviderworld.com/ It's basically going to be a directory of service providers across the world - that's the plan as I understand it. End-users can visit and review their service providers etc. Personally, I think this is a great concept - I've seen some online directories of providers and most of them are either entirely Canada based or US based and in my opinion not that great. Please bear in mind that this site is literally getting started - there is an email link I found at the bottom of the site where you can email the group for assistance/questions/feedback. Just an FYI ... Thanks, Paul

3 4

Re: [Nanog-futures] Admission for Committee Members
by Randy Bush 03 Sep '11

03 Sep '11

i do not support getting paid for community service. a primrose path. randy

12 21