September 2011 - Test - lists.nanog.org

Point to MultiPoint VPN w/qos
by Positively Optimistic 06 Sep '11

06 Sep '11

Greetings We have acquired a new client that has 98 remote endpoints. At each site there is a need for 4 ip telephones and two vpn tunnels back to two separate datacenters. (1 voice, 1 citrix farm). The sites don't talk to each other, just to the two data centers. Does anyone have a suggestion for a single piece of hardware that would support 8 or less Ethernet interfaces and the two vpn tunnels ? Thanks -Optimistic

10 12

Do Not Complicate Routing Security with Voodoo Economics
by Randy Bush 06 Sep '11

06 Sep '11

[ 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 <randy(a)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…

16 29

RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days
by Frank Bulk 06 Sep '11

06 Sep '11

I just noticed that the quad-A records for both those two hosts are now gone. DNS being what it is, I'm not sure when that happened, but our monitoring system couldn't get the AAAA for www.qwest.com about half an hour ago. Hopefully CenturyLink is actively working towards IPv6-enabling their sites again. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Thursday, August 18, 2011 11:14 PM To: nanog(a)nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days FYI, the issue is not resolved and I've not heard from either of the companies suggesting that they're working on it. Note their commitment to IPv6 in these releases: http://www.prnewswire.com/news-releases/centurylink-joins-internet-community -in-world-ipv6-day-123089908.html http://news.centurylink.com/index.php?s=43&item=2129 Frank -----Original Message----- From: Matthew Moyle-Croft [mailto:mmc@internode.com.au] Sent: Thursday, August 18, 2011 7:08 PM To: Owen DeLong Cc: nanog(a)nanog.org Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days On 19/08/2011, at 4:18 AM, Owen DeLong wrote: It'd really suck for end users to start actively avoiding IPv6 connectivity because it keeps breaking and for organisations that have active AAAA records to break peoples connectivity to their resources. +1 -- I'm all for publishing AAAA records as everyone knows, but, if you publish AAAA records for a consumer facing service, please support and monitor that service with a similar level to what you do for your IPv4 versions of the service. The coming years are going to be difficult enough for end-users without adding unnecessary anti-IPv6 sentiments to the mix. Owen +1 to Owen's comment. I'd also add some more comments: A lot of eyeballs that have v6 right now are the people with a lot of clue. Do you want these people, who'll often be buying or recommending your services to rate your ability to deliver as a fail? Our experience with IPv6 consumer broadband has been that the early adopters are the people who, well, goto IETF meetings, follow standards and ask the bloody hard questions. Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as HE?? :-) ) most end users prefer IPv6 over IPv4. Deeply this means there is a tendency for v6 traffic to grow and be more important to connectivity than you may imagine. The tipping point for IPv6 traffic being dominant I suspect is going to be a lower threshold of take up than people might expect. Consider this when thinking about the level of thought you give to IPv6 infrastructure and PPS rates. MMC

6 8

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