- Test - lists.nanog.org

Re: YouTube IP Hijacking
by Hank Nussbacher 26 Feb '08

26 Feb '08

At 03:14 AM 25-02-08 -0500, Paul Wall wrote: >Results were planned to be presented at the next NANOG, but they >shouldn't be a surprise to anyone in the industry: nobody filters. Incorrect. Some do filter and do it well. Problem is that it is in general a minority - many of which can be found here on NANOG. -Hank

6 7

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

26 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote: >No, most operators do filter BGP announcements. I know it, because I >have read it on Cnet: > >http://www.news.com/8301-10784_3-9878655-7.html > Dunno -- looks like McCullagh got it pretty much spot on: "At the moment, large network providers tend to trust that other network providers are behaving reasonably--and aren't intentionally trying to hijack someone else's Internet addresses. And errors that do arise tend to be fixed quickly by manual intervention." I may have missed it, but I didn't see any account of pervasive BGP filtering being done in the Internet... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHw9wPq1pz9mNUZTMRAn86AJ9rsXAoSVKt5MZl1qJiyDwW5SuhngCfToYR pmt3PBk5LYSAazZBtVR5yfs= =Ov9W -----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

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

25 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Daniel Roesen <dr(a)cluenet.de> wrote: >On Sun, Feb 24, 2008 at 10:41:26PM +0000, Paul Ferguson wrote: >> 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. > >http://www.ris.ripe.net/myasn.html Nice. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHwgarq1pz9mNUZTMRAgXEAJwI9hkG66kj1aF3hcjtqoaQoV35vgCeObJL 8LNjLeAyEwamVIEEox37f90= =bYgW -----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/

4 5

Rep : YouTube IP Hijacking
by Jean-Michel Planche 25 Feb '08

25 Feb '08

>If someone comes up with the anti-mistake routing protocol ... We could try to invent more idiot proof protocols, but the more control (and centralization), the more it will be "a kind of Internet". Not sure the founding principles and factors that made the Internet successful would resist anymore. Anyhow, you can think all you want about security, such as Apple with its concept of his locking iPhone, but you can’t anticipate the unexpected, like the ‘jailbreaker’ success ... and peoples acting on their routers with their feet and not with their brain and their hands. It's the nature of Internet technology: something could always fail and the ability to prepare for the unexpected is one of the reason why it works and is so scalable. It's also why "best effort" / "real knowledge" / education are better approaches than searching for yet another killer secure protocol. But maybe I'm a dreamer :-)) Anyhow, I’m not saying that nothing can be done. I can see at least two possibilities: 1/ What measures can be taken to prevent such things from happening and great discussion about it on the list. 2/ How can we take a more proactive approach and be informed of such incidents as soon as they occur and not after the first customer complaint On first issue,a lot to do ... If ‘best effort’ is something that always exist in the today business world, I think we’ll arrive at an equilibrium without waiting for geni.net (certainly good) answers. On second issue, there are plenty of possibilities and it's not difficult now to be informed to the minute when "big destination / AS" seems to be in trouble. FYI, just see: a very interesting TCP traceroute yesterday, during the "mistake" on Youtube (seen from our system / AS15436 on US East coast, Europe (Paris and London) http://www.flickr.com/photos/jmplanche/2291442426/ http://www.flickr.com/photos/jmplanche/2290636351/ : routing changed http://www.flickr.com/photos/jmplanche/2290636277/ : Youtube.com unreachable http://www.flickr.com/photos/jmplanche/2290636131/ : very interesting, there is an abnormally high response time, just before severe breakdown. Is Pakistan trying to announce more and more Youtube address and less and less Youtube servers available to answer ? http://www.flickr.com/photos/jmplanche/2291429544/ : not the same "overload" just before crash as seen from FR and UK : http://www.flickr.com/photos/jmplanche/2291429414/ ----------------------------- 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

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