February 2008 - NANOG - lists.nanog.org

Rép : YouTube IP Hijacking
by Jean-Michel Planche 25 Feb '08

25 Feb '08

Le 25 févr. 08 à 02:42, Patrick W. Gilmore a écrit : > > On Feb 24, 2008, at 7:36 PM, Tomas L. Byrnes wrote: > >> 1: Hosted at a Tier 1 provider. > > That is a silly requirement. > > (I am sorry, I tried hard to find a nicer way to say this, but I > really feel strongly about this.) > > >> 2: Within a jurisdiction where North American operators have a good >> chance of having the law on their side in case of any network outage >> caused by the entity. > > This is also a bit strange. Do your users never attach to a host > outside the USofA? Wasn't it humour / joke / troll :-) ? If not, maybe we've to follow discussion on nnsquad (Network Neutrality Squad) mailing list ? :-)) ----------------------------- Jean-Michel Planche blog: http://www.jmp.net Chairman and co-founder Witbe web : http://www.witbe.net Follow me http://www.twitter.com/jmplanche ------------------------------------------- 2.0 Monitoring : relevant End to End monitoring for critical app. and carrier class services

1 0

Peering Survey 2008 (http://tinyurl.com/3xoa6g)
by Greg Hankins 25 Feb '08

25 Feb '08

As a follow up to the presentations introducing the peering survey at NANOG and APRICOT, we'd like to announce it to the NANOG mailing list in order to get as many people as possible to participate. What is it? - New survey on how people configure peering! - Featuring technical questions on what protocols and features are used - It will take you under 10 minutes to answer 24 easy questions - No questions on facilities, IXs, or policies - No personal or identifying information will be used How does it work? - You take the survey here: http://tinyurl.com/3xoa6g (http://www.surveymonkey.com/s.aspx?sm=hy_2bvVcxxszICLYRFzPAjMw_3d_3d) - Results will be presented at the GPF 3.0 (and future conferences) Example Questions: - Do you use IPv6 unicast BGP peering? - Do you use BFD? - Do you use four byte ASNs (RFC 4893)? - What is the largest frame size you use on peering links? - What is your biggest concern when deploying a new feature? - Note: is it OK to say that you don't know what a feature is What is the purpose of the survey? - Identify trends in feature and protocol deployment - Educate the community on features and best practices Thanks for your participation! Greg Hankins (Force10) Ren Provo (Comcast) Tom Scholl (AT&T)

1 0

FCC listens
by bmanning＠vacation.karoshi.com 25 Feb '08

25 Feb '08

marginal relevence to network operations in statistically significant portions of North America. Some folks asking for Internet regulation. (again) http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-280373A1.pdf --bill

2 1

IX port security
by Greg VILLAIN 25 Feb '08

25 Feb '08

Hi all, Thinking back about this thread we've had lately around IXes, I have some extra questions. It is I assume the IX's responsibility to protect members from harming each other through the peering LAN. For that purpose, the IX has to do some minimum sanity checks before letting a member in into the production VLAN, for instance by using a quarantine VLAN to probe its traffic first. Then, once those checks are done, the IX shall apply a minimum security configuration to each member port: 1/ limiting broadcast/unknown unicast on each member port 2/ filtering bpdu 3/ locking mac addresses Here are my questions: - re 1/, any clue about the PPS or %bandwidth values to be configured to limit broadcast/unknown unicast ? - re 3/ should a certain number of allowed mac-addresses be configured to the port (1 or 2) ? or should the customer's port mac be explicitly configured on the port ? - more importantly, is there any other standard precaution that I'm missing and that should be considered ? cheers, Greg VILLAIN Independant Network/Telco Architecture Consultant

5 5

RE: Some ideas on how to protect against longer-prefix hijacking
by David Freedman 25 Feb '08

25 Feb '08

>1: Per my prior message, create a "SuperAS" that highly trusted entities How do we qualify those, are they linked to the amount of revenue we would lose from customers if they can't reach them? Can I be one of those? :) >2: Have some sort of algorithm that inversely relates AS number to longest prefix accepted from AS Number? these things are not related and this is not useful. RIRs such as the RIPE NCC have recommendations about the longest prefix they will "allocate" to an LIR from a particular /8, see document RIPE-415 section 4 >3: Filter prefixes longer than some constant * number of ASes in path, as opposed to some raw filter. Do not >aggregate, simply do not import at all. I'd say that you should accept /24 only from 2 hops or less, /20 from >3, and maximum/default from beyond. This is simply not practical, networks usually have little control over how many ASNs sit between them and networks they want to reach, this is a matter of routing policy. Also, IRR filtering, whilst a wonderful idea, is hugely impractical as a blanket suggestion, mainly down to untidy IRR data and sheer numbers of prefixes involved as you look at some of the larger networks. For instance, I did a brief study of the top 5 peers at the LINX by prefix count recently, unrolling their IRR Macros yielded nearly 330k prefixes Since we all already started developing a secure framework for BGP , I think we should just pick up the pace a little on this, if anything. Dave.

1 0

Some ideas on how to protect against longer-prefix hijacking
by Tomas L. Byrnes 24 Feb '08

24 Feb '08

Fundamentally, this is a policy issue, and the implementation details will need to be worked out, but today's event with YouTube is an exclamation point on a problem many of us have been wrestling with for some time: the advertising of unused but non-bogon address space by cybercriminals. Whether accidental or not, the black-holing of Youtube by Pakistan Telecom demonstrates a serious weakness in the "longest prefix wins" rule: there is no concept of trust contained in it. Trust, whether implicit or explicit, is inherent in all human interactions, yet expressing it in cyberspace has continued to be troublesome. In routing decisions, once you are beyond a connected (either directly or multi-hop) peer, it becomes much more difficult. I'm going to stay away from the political issues here, because I've been told to, but I think they really need to be weighed. Just as the companies we each work for or run take into account the regulatory framework and rule of law in the jurisdictions in which we do business (and use those as metrics on whether to do business at all in many places), I think it is wise to take those items, as well as other matters that play into trustworthiness, into account when choosing to accept routing information. So, let's start with some observations (I'm very willing to be corrected): Due to history and network geography, the distribution of longer prefixes is not uniform in the Internet. While there are exceptions, the vast majority of /22s and longer are in low-numbered ASes in North America, Europe, and AUSNZ. Due to a greater level of general civility, the prevalence of the rule of law, and the ability to have recourse against rogue operators, the incidence of rogue routing information from the locations above is orders of magnitude lower than that outside of it. Most North American Operators are, if not a full backbone themselves, directly connected to a true backbone provider, and therefore only 2 hops to any serious website. For North American operators, long prefixes advertised 3 or more BGP hops away are frequently forged. So, here are a few proposals: 1: Per my prior message, create a "SuperAS" that highly trusted entities (like MS, Google, Yahoo, etc) directly peer with, who everyone else peers with for routing information, from which ANY prefix-length will be accepted. 2: Have some sort of algorithm that inversely relates AS number to longest prefix accepted from. IE, you would accept a longer prefix with 701 as the originator (not the advertising peer) than 17557. 3: Filter prefixes longer than some constant * number of ASes in path, as opposed to some raw filter. Do not aggregate, simply do not import at all. I'd say that you should accept /24 only from 2 hops or less, /20 from 3, and maximum/default from beyond. These are simple ideas on how, without adding a whole lot of complexity, we might address some of the issues highlighted by today's "accident". Just trying to offer solutions that could be implemented easily. I'm sure many smarter than I can come up with better ones.

1 0

RE: YouTube IP Hijacking
by Paul Ferguson 24 Feb '08

24 Feb '08

-- "Tomas L. Byrnes" <tomb(a)byrneit.net> wrote: >It seems to me that a more immediately germane matter regarding BGP >route propagation is prevention of hijacking of critical routes. > The best you can _probably_ hope for is a opt-in mechanism in which you are alerted that prefixes you have "registered" with the aforementioned system are being originated by an ASN which is not authorized to originate them. A lot of smart folks have given some thought to this exact issue, and perhaps one of the best examples of this is: "PHAS: A Prefix Hijack Alert System" Mohit Lad, Dan Massey, Dan Pei, Yiguo Wu, Beichuan Zhang, and Lixia Zhang Proceedings of 15th USENIX Security Symposium 2006 http://www.cs.ucla.edu/~mohit/cameraReady/ladSecurity06.pdf - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Re: YouTube IP Hijacking
by Sena, Rich 24 Feb '08

24 Feb '08

<Jake Blues mode> I hate Cyber Jihads! </Jake Blues mode> ----- Original Message ----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: Neil Fenemor <neil.fenemor(a)fx.net.nz> Cc: Will Hargrave <will(a)harg.net>; nanog(a)merit.edu <nanog(a)merit.edu> Sent: Sun Feb 24 16:06:50 2008 Subject: RE: YouTube IP Hijacking Clearly, they are incensed by youtube content, so what makes anyone think that they would not be trying to engage in a case of Cyber-Jihad? I hosted the site that was rated #1 on Google for the Jyllands Posten (di2.nu) cartoons when it was a current issue, and I STILL get lots of script kiddie DOS from the Islamic world. I generally don't assume malice when mere incompetence will suffice, but in the case of the Islamic world, they've proved themselves malicious towards the non-Islamic world often, and violently, enough, that I don't believe they deserve that presumption of innocence any more. In either case, the correct COA is to filter all advertisements with AS 17557 in the path, until they fix the routes they are advertising, and let us know how they plan on making sure this doesn't happen again. > -----Original Message----- > From: Neil Fenemor [mailto:neil.fenemor@fx.net.nz] > Sent: Sunday, February 24, 2008 1:01 PM > To: Tomas L. Byrnes > Cc: Will Hargrave; nanog(a)merit.edu > Subject: Re: YouTube IP Hijacking > > While they are deliberately blocking Youtube nationally, I > suspect the wider issue has no malice, and is a case of > poorly constructed/ implemented outbound policies on their > part, and poorly constructed/ implemented inbound polices on > their upstreams part. > > On 25/02/2008, at 9:49 AM, Tomas L. Byrnes wrote: > > > > > Pakistan is deliberately blocking Youtube. > > > > http://politics.slashdot.org/article.pl?sid=08/02/24/1628213 > > > > Maybe we should all block Pakistan. > > > > > > > >> -----Original Message----- > >> From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] > On Behalf > >> Of Will Hargrave > >> Sent: Sunday, February 24, 2008 12:39 PM > >> To: nanog(a)nanog.org > >> Subject: Re: YouTube IP Hijacking > >> > >> > >> Sargun Dhillon wrote: > >> > >>> So, it seems that youtube's ip block has been hijacked by a more > >>> specific prefix being advertised. This is a case of IP > >> hijacking, not > >>> case of DNS poisoning, youtube engineers doing something > >> stupid, etc. > >>> For people that don't know. The router will try to get the most > >>> specific prefix. This is by design, not by accident. > >> > >> You are making the assumption of malice when the more > likely cause is > >> one of accident on the part of probably stressed NOC staff > at 17557. > >> > >> They probably have that /24 going to a gateway walled garden box > >> which replies with a site saying 'we have banned this', > and that /24 > >> route is leaking outside of their AS via PCCW due to dodgy > >> filters/communities. > >> > >> Will > >> > > Neil Fenemor > FX Networks > > >

1 0

Re: YouTube IP Hijacking
by Paul Ferguson 24 Feb '08

24 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Will Hargrave <will(a)harg.net> wrote: >Sargun Dhillon wrote: > >> So, it seems that youtube's ip block has been hijacked by a more >> specific prefix being advertised. This is a case of IP hijacking, not >> case of DNS poisoning, youtube engineers doing something stupid, etc. >> For people that don't know. The router will try to get the most specific >> prefix. This is by design, not by accident. > >You are making the assumption of malice when the more likely cause is one of accident on the part of probably stressed NOC staff at 17557. > >They probably have that /24 going to a gateway walled garden box which replies with a site saying 'we have banned this', and that /24 route is leaking outside of their AS via PCCW due to dodgy filters/communities. > I guess you guys missed the news that Pakistan has "blocked" YouTube due to [mumble]: http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/02/24/wpak324.xml AS Name AS17557 PKTELECOM-AS-AP Pakistan Telecom - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHwdp8q1pz9mNUZTMRAt4kAKDxryR8tLk3ejGe0p2aBAvvIcanAwCg4JkC a79WB3j06mIwUPdxUI+xweA= =zTdh -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Power Fun at 151 Front Street, Toronto
by Joe Abley 23 Feb '08

23 Feb '08

Hi all, Today is Diesel Day at 151 Front Street, where the building owner shuts down all grid power to allow intrusive power maintenance to happen, and the building is fed by generator power only. At least one suite on the 6th floor has been affected by a generator failure, so far. Just thought I'd pass on the news, in case there's anybody here who is scratching their heads about equipment or sessions down in Toronto which seem to have no rational cause. Most ISPs in the building (and the TorIX) have engineers on-site; if you have equipment located there which needs some TLC and you have no immediate/regular access to remote hands, let me know off-list and I'll try to put you in touch with someone who has appropriate access: I'm not on-site, but I have phone numbers for people who are. Joe

2 1