- Test - lists.nanog.org

A RR Wildcards and Stability
by Daniel Karrenberg 08 Oct '03

08 Oct '03

The comittee should realise that the question Verisign poses about observed adverse effects, while interesting, is not as pertinent as it seems at first sight. John Klensin put it very well yesterday in a rigorous way. I'll offer a less rigorous but more graphical analogy: A contractor drills large holes in the central structural parts of a building to allow installation of their innovative garbage disposal. Civil engineers question the effects this has on the building's stability. The contractor's defense is: "Well it is still standing! How much work did those tenants really have patching up the holes to reduce the air drafts and stop the crackling noises?" Daniel

3 2

Re: South America NOG ?
by Eric Kuhnke 08 Oct '03

08 Oct '03

Whoever is running the mailing list server linked from enred.org ( http://mailman.reacciun.ve/mailman/listinfo/enredo ) should update their Apache very soon... http://www.securiteam.com/exploits/5JP0G204KG.html The requested URL /pipermail/directorio-enred/ was not found on this server. Apache/1.3.17 Server at <mailto:hostmaster@reacciun.ve>mailman.reacciun.ve Port 80 >And you can find them at http://www.enred.org >The mailing list link is in the upper right hand corner. > >--Michael Dillon

1 0

Sitefinder study released
by Michael.Dillon＠radianz.com 08 Oct '03

08 Oct '03

Now this is the kind of thing that we need to combat Verisign. http://cyber.law.harvard.edu/tlds/sitefinder/ The data presented here exhaustively shows that Verisign's whole business model is flawed because they don't really control this "diversion" of traffic and ISPs can and will block the diversions at source with DNS patches and routing. This particular paper puts pressure the companies that are paying Verisign for the Sitefinder service. We still need more papers that describe the negative technical impacts of sitefinder and we need those papers to be published somewhere, not just on the NANOG mailing list. At minimum, you should send copies to both ICANN and to the Berkman Center (read the above paper for a URL). --Michael Dillon

1 0

Re: South America NOG ?
by Michael.Dillon＠radianz.com 08 Oct '03

08 Oct '03

>foro de redes has been going on since '91. the mailing list is >enredo. And you can find them at http://www.enred.org The mailing list link is in the upper right hand corner. --Michael Dillon

1 0

Re: Transit and Paid Peering Exchanges
by Daniel Golding 08 Oct '03

08 Oct '03

Dennis, I'm not really looking at normal exchanges where some participants offer transit or partial transit. I'm looking at exchange fabrics specifically set up for the purpose of selling services, be they transit, partial transit, or paid peering. Most of these exchanges have web based administration, route servers, flow accounting, or some other combination of services. A good example is Equinix's Equinix Direct. Equinix maintains a series of exchange fabrics that are primarily for settlement free peering, but also has exchange fabrics set up, specifically, for buyers and sellers of services. Telehouse in NYC was doing something like this, as well. I'm not sure how far it has progressed. Thanks, Dan > From: "Dennis Jewth" <Dennis.Jewth(a)xchangepoint.net> > Date: Wed, 8 Oct 2003 10:03:41 +0100 > To: "Daniel Golding" <dgolding(a)burtongroup.com> > Cc: <nanog(a)merit.edu> > Subject: Re: Transit and Paid Peering Exchanges > > Hi Daniel > > Really you need to reword that as exchanges used for peering and transit > provision/delivery, over which some networks may be paying for peering > sessions. > > We run a MAN in London connecting 7 co-lo's (including THouse North) that is > used as the > delivery platform for transit from the Carriers to ISPs and hosting > companies. We are also a peering point. > > Paid peering is more common in the US. In Europe some of the larger networks > are talking about offering paid peering (and there may be already few doing > it). It's to > get that info out in the open from those doing it that's harder (hence your > mail > to Nanog, no doubt). > > Are you looking at partial transit as well? > > Dennis Jewth > XchangePoint Europe > www.xchangepoint.net > > > ----- Original Message ----- > From: "Daniel Golding" <dgolding(a)burtongroup.com> > To: <nanog(a)merit.edu> > Sent: Wednesday, October 08, 2003 9:31 AM > Subject: Transit and Paid Peering Exchanges > > >> >> >> Doing some research.... >> >> Anyone have a list of Transit and Paid Peering exchange fabrics? >> >> I am interested in both US and EU locations, particularly in interesting >> sites like 111 8th Ave (NYC), Telehouse North (London) and other major > telco >> hotel type facilities. >> >> I'll summarize for the list and repost. >> >> Thanks, >> -- >> Daniel Golding >> >> > > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ________________________________________________________________________ >

1 0

Re: kooky BGP tricks
by E.B. Dreger 08 Oct '03

08 Oct '03

DG> Date: Wed, 08 Oct 2003 09:31:45 +0200 DG> From: Daniel Golding DG> 1) In a way, its fraudulent If not mutually agreed in advance between 65000 and 65100, yes. This is analogous to announcing more specifics from another provider's space. DG> 2) Some folks do BGP traffic engineering tricks using AS path. Other folks DG> do measurement stuff using AS-Path. Therefore, wrong AS paths are bad. True. Seeing "1239 $smallprovider 701" would be a bit bizarre, pretending for a moment that 1239 accepted "$smallprovider 701". DG> 3) Hacks are unscalable. This is a hack. In a sense. In another sense, it's like 65000 sending 65100 partial routes... except it's actually a subset of 65000 doing the talking. I should have been more clear in my post. I originally was addressing the issue of $smallprovider peering with a transit AS when $smallprovider's upstream wouldn't. Ghetto multihoming was a poorly-added afterthought, and probably muddled the question. :-/ DG> Why doesn�t AS65100 just advertise the routes as "65100 65100 i" or "65100 DG> i"? What is gained by doing "65100 65000 I" other than ensuring that if the DG> link between $downstream and AS65000 goes down, then $downstream becomes DG> unreachable from AS65000 due to BGP loop detection? I've always seen inconsistent origin ASNs as "evil". They work, but are generally frowned upon... perhaps it is the lesser of evils, though. DG> If I were AS65000, I might be disposed to complain to AS65100's upstream or DG> to the large community about 65100 stealing my AS. I would suspect some evil Again, I meant to indicate 65000 and 65100 agreed in advance. DG> intent. Also, if $downstream cant afford $500 for an AS, what makes anyone DG> think they can afford to pay either upstream? Very true. And ASNs are still plentiful; running out is far enough down the road not to worry... Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division 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 : blacklist(a)brics.com -or- alfra(a)intc.net -or- curbjmp(a)intc.net Sending mail to spambait addresses is a great way to get blocked.

1 0

kooky BGP tricks
by E.B. Dreger 08 Oct '03

08 Oct '03

Greetings all, Time for the "kooky routing idea of the year" post... Scenario: AS65000 is a bandwidth provider. One of their downstreams wishes to peer with AS65100, or to multihome with AS65100 as a second upstream. The obvious and 100% correct answer is for $downstream to register their own ASN, that anyone ready to multihome or peer can afford $500 up front and a few bucks per year. We all know this. However, $downstream wishes to advertise the routes without registering an ASN. AS65100 decides to advertise $downstream's prefixes as 65100 65000 ? exactly as if 65000 were sending only $downstream's routes to 65100. From a technical perspective, this works. Yes, there are issues with more-specifics and perhaps loop detection. The question: What would your reaction be if you were AS65000? Note that this is a political/admin question, _not_ a technical one. My thoughts: >From an administrative perspective, this can get messy, but is doable iff 65000 and 65100 agree in advance. The IP space analog is done routinely. I'd not mind being either 65000 or 65100 -- _iff_ both ASNs agreed in advance. Cutting down on leaf ASNs without causing inconsistent ASNs seems like a reasonable goal. Wrapping self in flameproof insulation... Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division 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 : blacklist(a)brics.com -or- alfra(a)intc.net -or- curbjmp(a)intc.net Sending mail to spambait addresses is a great way to get blocked.

1 0

New virus
by Andrew Fried 08 Oct '03

08 Oct '03

I just received an email proporting to be from Symantec that contained an anti-virus signature update. The message originated in the Netherlands. The attachment has been submitted to Symantec and FortiNet for review, however, I thought the community might want a heads up since I do not know the degree to which this has been distributed. The full content of the message I received is below: X-Persona: <CIS> Return-Path: <updates(a)symantec.com> X-Original-To: afried(a)cis.fed.gov Delivered-To: afried(a)cis.fed.gov Received: from node0938.a2000.nl (node0938.a2000.nl [62.108.9.56]) by mailserver.cis.fed.gov (Postfix) with SMTP id 22868FD52 for <afried(a)cis.fed.gov>; Tue, 7 Oct 2003 06:22:19 -0400 (EDT) Message-ID: <20031026614.2874.qmail(a)symantec.com> Date: Tue, 7 Oct 2003 03:26:29 -0700 From: <updates(a)symantec.com> Subject: Last Update. To: <afried(a)cis.fed.gov> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------9D16FAF1684605E" X-UIDL: G]m!!l"d"!b\E"!\]5"! October 06, 2003 Intruder Alert 4.1 W32_Webb_Worm Policy This policy detects the propagation of the W32.SobigF.Worm through changes in the registry. W32.Webb.F@mm is a mass-mailing, network-aware worm that sends itself to all the email addresses it finds in various files. The worm uses its own SMTP engine to propagate and attempts to create a copy of itself on accessible network shares, but fails due to bugs in the code. In attachment you can find program that update your Norton Antivirus to Norton Antivirus 2004. [nav32.zip] Scanned by evaliation version of Dr.Web antivirus Daemon http://drweb.ru/unix/

2 1

Anyone at Level3?
by Kee Hinckley 08 Oct '03

08 Oct '03

Looking for someone at Level3. While this pales in comparison to Cisco's DoS situation, my home DSL connection is currently getting slammed by a Level3 customer who has in the past week attempted to send me 2.6 million email messages in bursts that are swamping my connection--even though I reject them before we get the DATA. I've sent messages to Level3 abuse and securityoperations addresses several times over the past week, and I've called them on the phone. They downloaded my log file, but they've done nothing to either respond, or deal with the problem. It's not like the guy is an unknown quantity, see: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL6857 http://www.spamhaus.org/sbl/sbl.lasso?query=SBL5576 He's known for the fact that he ignores 5x SMTP codes. Which is all very fine, but it doesn't explain why he's trying to blast me off the net. Just rejected another 10,000 connection attempts as I wrote this. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.

1 0

CCO/cisco.com issues.
by Roland Dobbins 07 Oct '03

07 Oct '03

Folks, We've been handling a multi-vector DDoS - 40-byte spoofed SYN-flooding towards www.cisco.com (198.133.219.25/32) as well as an HTTP-AUTH resource-exhaustion attack, and working these issues with our upstreams. Our apologies for any inconveniences, and our thanks to those who've assisted in tracing and blocking the spoofed traffic. We're continuing the work the issue, and would be grateful if operators would check for 40-byte spoofed TCP headed towards 198.133.219.25/32 and trace/block it as warranted. Your patience and understanding are greatly appreciated. Thanks! ------------------------------------------------------------- Roland Dobbins <rdobbins(a)cisco.com> // 408.527.6376 voice

16 20